cc @jxnblk

cc @alexindigo @DullReferenceException

フィードバックをお寄せください👍

コードを試してみたところ、 assetPrefixを複数の部分に分割する方がはるかに簡単であることがわかりました。

module.exports = {
  host: NOW_URL ? `https://${alias}` : 'http://localhost:3000',
  basePath: '/account',
}

assetPrefix変数を内部的に保持することはできますが、ユーザーは必要なものをより正確に定義する必要があります。

アセット部分では、これら2つの変数を一緒に提供しても問題ありません。
ルーティングなどには、個別に必要です。
または、構成ファイルで一緒に提供してから、next.jsコードベースで分割することもできます。 この場合、assetPrefixは私が恐れている正しい名前ではありません。

副作用として、これはコードの変更も少なくなります。
これらの2つのPRを比較すると、非常に明白です。
https://github.com/panter/next.js/pull/2 （分割）
https://github.com/panter/next.js/pull/1 （両方を渡す）

私の意見では、彼らは別々である必要があり、その理由は、それが維持するために破壊し、より柔軟ではないということですassetPrefixし、持っているbasePath別々に。

assetPrefixは正しい名前ですか？ 両方の変数は実際には接頭辞ですよね？

assetPrefixはアセット用です。例：ページバンドル。 basePathはルーター用になります。

それが機能するはずの方法は次のとおりです。

• assetPrefixが定義されている場合は、 assetPrefixを使用してバンドルをロードし、ルーターに触れないでください（現在の動作）
• assetPrefixとbasePathが提供されている場合は、 assetPrefixを使用してバンドルをロードし、ルーターにbasePathを追加します
• assetPrefixが定義されておらず、 basePathが定義されている場合は、 basePathを使用してバンドルをロードし、ルーターにbasePathを追加します。
• assetPrefixもbasePathも定義されていない場合、何も変わりません（ assetPrefixが提供されていない場合の現在の動作）

cc @alexindigo @DullReferenceException @ 3rd-Eden

上記の提案についてフィードバックをお寄せください： //github.com/zeit/next.js/issues/4998#issuecomment -414978297

@tomaswitek現在のassetPrefixで何が正確に機能しなかったかはわかりません。これは、"assetPrefix":"https://static.trulia-cdn.com/javascript"あり、期待どおりに機能します。

また、一般的に、同じドメインで複数のゾーン（アイランドと呼びます）を使用しており、アイランド間の相互運用性が複雑になるため、各アイランドの「basePathing」は思い浮かびませんでした。 tatについてもう少し詳しく説明します。

つまり、2つの島AとBがあり、その主なアイデアは、1つのWebサイトエクスペリエンスの一部として島から島へと移動するユーザーの透明性です。 したがって、島の間にはリンクがあるはずです。 次に、展開の問題とアプリケーションの問題があります。

1. 展開の懸念とアプリケーションの懸念–アプリケーションはどこに展開できるかわからず、着信http要求を処理する方法を知っているだけです–応答できるルートを設定しました。
   どこかにデプロイされた場合–異なるドメイン、異なるポートである可能性があり、理論的には異なるbasePathである可能性があり、プロキシまたはその他の手段を介してアプリに対して透過的になります。

2. アイランド間のクロスリンク–アイランドの精神を個別の展開可能なエンティティとして維持するために、異なるアイランド間で内部実装の知識が漏洩することはありません。
   したがって、島がお互いのページを参照するための最良の方法は、他の島が消費するために利用可能なルートをエクスポートすることです（_そしてnextjsの世界では、カスタムの<IslandALink>種類のコンポーネントが好まれるようです仕方_）。
   これまでのところ、それはすべて簡単です。すべての島は同じドメインを共有し、絶対パスのセット（ /path1 、 path2など）を持っていると想定しています。 そうすれば、2番目の島はそのパスのリストをインポートし、安定するためにそれに依存します。 同時に、各アイランドが下位互換性を維持するための最小限の要件です（とにかくWebでは良いことです）:)

デプロイメント固有のbasePathを追加すると、システム全体の複雑さが自動的に増加します。各アイランドは、独自のデプロイメントbasePathを認識している（そしておそらく指示している）必要がありますか？ それでは、現在の動作とどのように違うのでしょうか。 または、アイランドAはその展開パスにとらわれない必要がありますか？ それでは、島Bは、島Aが自分自身について知っていることしか知らないので、展開された島Aをどのように見つけるのでしょうか。 または、デプロイされたすべてのアイランドのbasePathを他のすべてのアイランドに提供する必要がありますか？ そして、物事を展開する現代的な方法では、新しい島を追加する必要があるときにすべての島を再展開することを意味します。

それとも、物語のその部分をどのように想像しましたか？

ありがとうございました。

^それは朝のコーヒーの前に書かれたので、それのいずれかの部分についてもっと首尾一貫した説明が必要な場合は私に知らせてください。 :)

まず、私の問題を確認するために時間を割いてくださった皆さんに感謝します。

@timneutkensはいassetPrefixはbasePathよりも優先されます。これは、最初に説明したとおりです。 変更する必要のあるファイルの数を確認した後、2番目の方法の方がクリーンだと思いました。 ただし、最初のソリューションにロールバックします。 それを完全に分離しておこう、まったく問題ありません。 私はただ大声で考えていました。

あなたの詳細な答えのための@alexindigoThx 。 あなたの質問に答えてみましょう😏

現在のassetPrefixで何がうまくいかなかったのかわからない

ここで2つの問題があります。

1. 現在のプロジェクトでは、複数のドメインやサブドメインを操作できません。 （ドメイン制限とワイルドカードSSL証明書なし）
2. 単一ドメインでのassetPrefixの現在の実装では、プロキシルーティング、静的ファイルなどをさらに調整する必要があります。 basePath導入することで、この調整を減らすことができます。 @timneutkensがすでに述べたように、 basePathを提供する必要がないため、何もブレーキをかけず、複雑さを増すことはありません。

アプリケーションはどこにデプロイできるかわかりません

もちろん、ここでも同じ目標があります。 現在のソリューションでは、assetPrefixesを動的に定義しています。 プロキシによるリクエストヘッダーを介して提供されます。

それでは、現在の動作とどのように違うのでしょうか。

ルーターはcontextPathを認識し、カスタムコードの量を減らします。

各アイランドは、それ自体のデプロイメントbasePathを知っている（そしておそらく指示する）必要がありますか？ または、アイランドAはその展開パスにとらわれない必要がありますか？

そうである必要はありません。 開発者はここで自由を持つべきです。 AssetPrefixと同じ方法でbasePathを動的に提供できるはずです。

それでは、島Bは、島Aが自分自身について知っていることしか知らないので、展開された島Aをどのように見つけるのでしょうか。 または、デプロイされたすべてのアイランドのbasePathを他のすべてのアイランドに提供する必要がありますか？ そして、物事を展開する現代的な方法では、新しい島を追加する必要があるときにすべての島を再展開することを意味します。

たぶん、basePathをルートエクスポートに追加することもできます。 知りません。 basePath変数がすべてのユースケースにとって重要であると言っているわけではありません。 それはあなたにとって最善の解決策ではないようです。 しかし、それはまったく問題ありません。 重要なのは、 assetPrefixだけを使用でき、島では何も変わらないということです。 とにかく独自のルーティングがあるようです。 ゾーン間のクロスリンクは、私たちのプロジェクトにとっても重要ではありません。私たちのゾーンは本当に独立していて、互いに分離されています。

そして、物事を展開する現代的な方法では、新しい島を追加する必要があるときにすべての島を再展開することを意味します。

理由がわかりません。 一部のゾーンにはbasePathがあり、一部にはないことも想像できます。 また、一部のアプリは、マルチゾーンが設定されていなくてもbasePath構成を使用する可能性があります。

@alexindigo plsは、next.jsによってレンダリングされる2つの実際の島のURLを提供して、実際の動作を確認できますか？ 見つけようとしましたが、ドメインで_nextリクエストのあるページが見つかりません
すべての島の構成は同じですか？
"assetPrefix":"https://static.trulia-cdn.com/javascript"

@tomaswitek

現在のプロジェクトでは、複数のドメインやサブドメインを操作できません。 （ドメイン制限とワイルドカードSSL証明書なし）

ああ、それであなたは古典的な意味でCDNを使用しませんが、各アプリから直接フェッチされるアセットに依存しますか？ そうですか。

単一ドメインでのassetPrefixの現在の実装では、プロキシルーティング、静的ファイルなどでさらに調整が必要です。basePathを導入することで、この調整を減らすことができます。 @timneutkensがすでに述べたように、basePathを提供する必要がないため、何もブレーキをかけず、複雑さを増すことはありません。

ところで、それは「いいえ、その機能を追加しないでください」ではありませんでした:)それはもっと似ていました–「おそらく私たちはこのアプローチをより全体的に考えることができます」:)

そうである必要はありません。 開発者はここで自由を持つべきです。 AssetPrefixと同じ方法でbasePathを動的に提供できるはずです。

はい。 ただし、島の間にリンクがない場合にのみ機能します。 そして、これがあなたのユースケースのように聞こえます。 同時に、100％独立している場合、スタンドアロンアプリケーションの集まりではなく、何がそれらを島にするのかを理解するのに苦労していますか？ :)

たぶん、basePathをルートエクスポートに追加することもできます。

ルートのエクスポートはビルド時に行われ、basePathはデプロイ時に定義され、同じコードアーティファクト（stage、preprod、prod、テスト環境など）。

すべての島の構成は同じですか？
"assetPrefix"： " https://static.trulia-cdn.com/javascript "

はい、すべての島が資産を共有しています。次はコンテンツハッシュを行うため、問題がないだけでなく、実際には非常に有益です。 （各アーティファクトからビルドされたアセットを抽出し、展開時にCDNで公開します）。

そうすれば、アプリサーバーへの「通常のhtml」リクエストのみがあります。これが、trulia.comに「_next」パスが表示されない理由です。

島の例について：

私たちの新鮮な真新しい島–近所のページ– https://www.trulia.com/n/ca/san-francisco/pacific-heights/81571 （そしてあなたはここでそれらの詳細を見つけることができます：http：//www.trulia。 com / neighborhoods）
この島はすべての/n/*パスを担当します。

そして別の島は私たちのログインページです– https://login.trulia.com/login –それは異なるドメインのように見えますが、実際にはそうではありません。さまざまな理由でそのように見えますが、技術的には同じ展開です。 :)
そして、この島は/login 、 /signupようなURLを処理します。

他にご不明な点がありましたらお知らせください。

@alexindigo例をありがとうございます。
例を分析した後、いくつか質問があります😄

まだすべての島でサーバーレンダリングを行っていますが、可能な限り多くのアセットを共通のCDNに抽出しようとしていますか？

https://www.trulia.com/n/ca/san-francisco/pacific-heights/81571が呼び出されたときに正確に何が起こるかをもう少し詳しく説明できますか？ プロキシは、 /nが近隣の概要を表し、それを適切な島に転送することを知っていますか？ 島に到着する前のリクエストに何らかの影響がありますか？

島内の次の場所から組み込みのルーティングを使用しますか、それともカスタムソリューションがありますか？
島内の経路を確認したかった。 残念ながら、 Neighborhood overviewは、URLを変更せずに、多かれ少なかれモーダルナビゲーションしかありません。 ログインには、完全にカスタムのソリューションがあるようです。

このコメントであなたのすべての質問に答えることを願っています😏

ところで、それは「いいえ、その機能を追加しないでください」ではありませんでした:)それはもっと似ていました–「おそらく私たちはこのアプローチをより全体的に考えることができます」:)

確かに、next.jsに触れる必要がない解決策を見つけるのは素晴らしいことです😏

はい。 ただし、島の間にリンクがない場合にのみ機能します。 そして、これがあなたのユースケースのように聞こえます。 同時に、100％独立している場合、スタンドアロンアプリケーションの集まりではなく、何がそれらを島にするのかを理解するのに苦労していますか？ :)

私は「島」の解決策を探していると書いたり言ったりしたことはありません。 @timneutkensとチャットしたところ、問題について説明しました。Timの答えは基本的にnext.jsはベースパスをサポートしていません。 そして少しグーグルした後、私はそれを探しているのは私だけではないことに気づきました。 だから少し貢献できると思いました。 その後、ティムは私にフィードバックを与えるようにあなたにpingしました、そして私はあなたのフィードバックにとても感謝しています。

ルートのエクスポートはビルド時に行われ、basePathはデプロイ時に定義され、同じコードアーティファクト（stage、preprod、prod、テスト環境など）。

ビルド時にルートをエクスポートして他のアイランドで使用できるようにする場合、最も簡単な方法は、構成でbasePathをハードコーディングすることです。 私はあなたの主張を理解します。 反対に、それは本当にそのような問題ですか？ アプリを異なるドメインやポートにデプロイすることも、環境ごとに同じbasePathを使用することもできます。

おはよう@tomaswitek :)

「basePath」機能に関する私の経験では、その複雑さを非常に騙しているので、通常は、特定の問題を1つ抱えることなく、そのようなものを実装する方がよいでしょう。
しかし、それを複数の角度から見ています。 ディープマージにアプローチする方法と同様に、複数のユースケースの概要を説明し、それらがすべて1つの傘下にあるかどうかを確認します。 フレームワークの（メジャーな）バージョン間で互換性のない機能があるので、非常に面倒です:)

アプリを異なるドメインやポートにデプロイすることも、環境ごとに同じbasePathを使用することもできます。

その「basePath」がルーティングコードの一部であるソリューションで問題ないように思えます。これは、最初に述べたものです。たとえば、 pagesディレクトリ内のサブフォルダーのように（ところで、そのアプローチは、選択した開発者に通知されます） basePathはかなりうまくいきます）。 しかし、あなたを止めた唯一のことは、アセット_next内部nextjsパスが構成できないことです。

そして、それは私たちがより少ない長期的な副作用で解決できるより狭い問題のように聞こえます。

また、アセットごとにassetPathを構成できる場合（たとえば、ある種のnext.configマップを使用）のように、さらに進化する可能性があります。これにより、アプリ間でアセットを共有できるようになり、パフォーマンスなどが向上します。

そして、その機能のためのオープンPRがあります。 ;）/ cc @timneutkensは、その子犬に戻る時間のようです。 :)

これをすぐに追加する予定がない場合は、これを実行して機能するExpressベースのserver.jsの例をreadmeに追加できますか？ 私はこれらの問題に浮かんでいるいくつかを試しましたが、それらを機能させることができませんでした。 ありがとう。

こんにちは@ccarse私はすでに本番環境で使用している作業用フォークを持っています： //github.com/panter/next.js/pull/2
また、この機能のPRを開くために時間を費やす準備ができています。
@timneutkens @alexindigoこの問題を解決する他の方法はありますか？
私たちが必要としない場合はbasePath設定を、あなたは、plsは私達に使用して、最小限の例与えることができますassetPath ？

私の会社もこれに反対しています。

従来のアプリをセクションごとにゆっくりと引き継ぎ、Next.jsに置き換えています。

簡単な例として：

| URL | アプリ|
| --- | --- |
| example.com | レガシー|
| example.com/shop | 次へ|
| example.com/search | レガシー|
| example.com/members | 次へ|

つまり、各Next.jsアプリ内ですべてにプレフィックスを付ける必要があり

Nowを使用していないため、 now.jsonルーティングを利用できないことにも注意してください。 ドメイン全体の前に独自のロードバランサーを配置し、サブパスに基づいてトラフィックをルーティングします。

カスタムサーバー（hapi）も使用しているので、ここで作成したものをカスタムサーバー内でも活用できれば便利です。

now.config.json設定の組み合わせや、これと同じことを実現するために使用できるマイクロプロキシの使用があるかもしれませんが、正しい組み合わせはまだわかりません。

Nowv2でホストされている複数の静的にエクスポートされたNext.jsアプリで同じ問題が発生していると思います。

| URL | アプリ|
| -| -|
| example.com | 次へ|
| example.com/dashboard | 次へ|

予想どおり、ルートアプリは問題なく動作します。 しかし、2番目のものでは物事がうまくいかない。 現在、 next/linkをラップしています。これを、 assetPrefixと組み合わせると、問題のほとんどが解決されます。

export default ({ children, href, ...rest }) => (
      <Link href={process.env.NODE_ENV === "production" ? `/dashboard${href}` : href} {...rest}>
        {children}
      </Link>
);

ただし、これはprefetch壊します。これは、間違ったURLで.jsファイルを検索しようとするためです。

• 実際のファイルのURL： https ：
• プリフェッチされたファイルのURL： https ：

現在の回避策はprefetchを無効にすることですが、これは理想的ではありません。

これの状況はどうですか？

また、これに関する更新を探してください。

@timneutkensコミュニティに興味があれば、PRを開くために時間を

これに対する解決策も必要です

この提案を廃止する新しいAPIを間もなく導入する予定です。

これも影響を受けます。 サブディレクトリパスの下で次のプロジェクトを実行する必要があります。 公式機能を楽しみにしています。 ETAはありますか？

API

それで、それはどうですか？ ：D

スレッドをスパムしないでください。問題自体にGitHubの👍機能を使用してください。

@timneutkensこれ以上の情報を提供できますか？ これを時代遅れにするAPIは何ですか？ 「すぐに」何を考えますか？ ありがとうございました。

これはマルチゾーンに正確に関連しているとは限りませんが、役立つ場合があります...

カスタムサーバーを作成し、プロキシミドルウェアを使用することで、これに似た問題を解決しました

例：@Zertz
注：リンクの問題を解決する必要があります-繰り返しますが、リンクコンポーネントを作成し、構成を介してプレフィックスをアプリに渡すことでこれを解決しました。プレフィックスが存在する場合は、静止画像の場合と同じように、それを使用するか、何も使用しません。

const proxy = require('http-proxy-middleware');

app.setAssetPrefix('/dashboard');

  // Express custom server
  // Proxy so it works with prefix and without...
  // So if asset prefix is set then it still works
  const server = express();
  server.use(
    proxy('/dashboard', {
      target: 'http://localhost:3000', 
      changeOrigin: true,
      pathRewrite: {
        [`^/dashboard`]: '',
      },
    }),
  );

私が言及した提案は＃7329です

私が言及した提案は＃7329です

@timneutkens
提案されたフックがベースパスの問題をどのように解決するかについて、詳細を教えていただけますか？
また、 Router.push('/about')ようなルーターリダイレクトもフックに置き換えられますか？

お時間をいただきありがとうございます😏

リンクするコンポーネントが必要になるため、ルーターAPIも変更されます。 その時点で、URL自体に相対パスを使用できます。

いつ解決策を得ることができるか、または少なくともこれに対する回避策についての更新はありますか？

更新を投稿する代わりに、最初の問題で👍を使用します。

@ MMT-LDあなたの解決策は私にとってはうまくいきますが、今ではすべてのリンククリックまたはルータープッシュイベントでページがリロードされます☹️

@Zertzのソリューションを試しましたが、完璧に機能しました。
また、出力ファイルをプリフェッチされたパスにコピーすることで、 prefetch問題を修正できました。
https://github.com/fand/MDMT/blob/master/scripts/copy-preload.js

...それは汚いトリックですが、とにかく機能しています🤪

@nicholasbraun

これで、リンククリックまたはルータープッシュイベントごとに、ページがリロードされます☹️

私はこの問題を抱えていましたが、リンクで「as」パラメータを使用して修正したため、リンクは内部ファイルを指しますが、「as」はパスに関連しています
例えば：
<Link href={"/${item.link}"} as={"./${item.link}"}>

@nicholasbraun

あなたの解決策は私にとってはうまくいきますが、今ではすべてのリンククリックまたはルータープッシュイベントでページがリロードされます☹️

これは私が意味したことの一種です。 これはメモリからです....しかし、以下から必要なものに到達できないと確信しています。

// WithConfig component
import getConfig from 'next/config';

const { publicRuntimeConfig } = getConfig();

const WithConfig = ({ children }) =>
  children && children({ config: publicRuntimeConfig });

export default WithConfig;

// Extended Link component

 import React from 'react';
import PropTypes from 'prop-types';
import Link from 'next/link';
import { WithConfig } from '../WithConfig';
/* 
    <Link> component has two main props:
    href: the path inside pages directory + query string. e.g. /page/querystring?id=1
    as: the path that will be rendered in the browser URL bar. e.g. /page/querystring/1

*/

const NextLink = ({
  browserHref,
  pagesHref,
  whatever,
}) => {
  return (
    <WithConfig>
      {({ config: { pathPrefix } = {} }) => (
        <Link
          as={pathPrefix ? `${pathPrefix}${browserHref}` : browserHref}
          href={pagesHref}
          passHref
        >
          <a>{whatever}</a> // this bit is up to you - children or whatever
        </Link>
      )}
    </WithConfig>
  );
};

NextLink.propTypes = {
  browserHref: PropTypes.string.isRequired,
  pagesHref: PropTypes.string,
};

NextLink.defaultProps = {
  pagesHref: undefined,
};

export default NextLink;

使用法：

import NextLink from '../NextLink'

<NextLink browserHref={`/page/1`} pagesHref={`/page?querystring=1`} whatever='I'm the link' />

頑張ってください：スマイリー：

useLink RFCが拒否され（＃7329）、 basePathサポートがあると大いに役立つので、Next.jsプロジェクトはそれを実装するPRを喜んで受け入れますか？ 私はそれを喜んでします。

@tomaswitekによるこの実装を見ると、正しい方向に進んでいるように見えます。最も重要なのは、ルーターにbasePath認識させることです。 basePathサポートを困難にする他の非自明なことはありますか？

全体として、設計は明確で、単一の構成変数だけだと思います。

module.exports = {
  basePath: '/demo'
}

assetPrefixとの相互作用は、 https ： ます。

更新：カスタムルーターを作成し、何らかの方法でデフォルトのルーターを交換することでこれを実装できるかどうかも考えていましたが、不可能なようです。Next.jsはルーターをハードコードします。たとえば、こちらを参照してください。 また、ルーターを「交換するだけ」で十分だとは思えません。 この機能は、おそらくNext.js全体でサポートされる必要があります。

この問題は2017年から発生していますが、回避策はありますか？ または、basePathリクエストへの公式の応答ですか？

したがって、 https ： assetPrefixとカスタム<Link>コンポーネントの組み合わせでこれを機能させようとした後-464345554またはhttps://github.com/zeit/next.js/issues/4998#issuecomment-521189412 、残念ながら、それができるとは思いません。

assetPrefix定義は比較的簡単で、 next.config.jsます。

const assetPrefix = process.env.DEPLOYMENT_BUILD ? '/subdir' : '';

module.exports = {
  assetPrefix,
  env: {
    ASSET_PREFIX: assetPrefix,
  },
}

次のステップは、カスタムLinkコンポーネントです。 たとえばhttps://github.com/zeit/next.js/issues/4998#issuecomment-464345554で与えられている最初のアイデアは、次のようにhrefのプレフィックスを付けることです（簡略化）。

export default ({ children, href, ...rest }) => (
  <Link href={`${process.env.ASSET_PREFIX}${href}`} {...rest}>
    {children}
  </Link>
);

このスレッドの他の人が報告しているように、リクエストが突然/ subdir /_next/static/.../pages/ subdir /example.jsに送られるため、プリフェッチが中断されLinkコンポーネントでは、hrefを/subdir/exampleに設定しているため、Next.jsがpages/subdir/example.jsページのバンドルをリクエストしているのも不思議ではありません。

さて、問題のあるプリフェッチは世界の終わりのようには聞こえませんが（UXはかなり醜いですが）、私たちのアプリでは、Next.js9の動的ルーティングを使用しているため状況が悪化します。 そのためには、 as適切に設定して、カスタムLinkコンポーネントの進化が次のようになるようにする必要があります。

export default ({ children, href, as, ...rest }) => (
  <Link 
    href={`${process.env.ASSET_PREFIX}${href}`}
    as={`${process.env.ASSET_PREFIX}${as}`}
    {...rest}
  >
    {children}
  </Link>
);

使用法は次のとおりです。

<CustomLink href='/post/[id]' as='/post/1'>...</CustomLink>

これは次のように変換されます：

<Link href='/subdir/post/[id]' as='/subdir/post/1'>...</Link>

Nowにデプロイしたときはまったく機能しませんhttps://deployment-id.now.sh/subdir/post/1に移動しようとすると404になります。理由はよくわかりません。おそらく、 @now/nextビルダーの問題でもあります（更新：https：//github.com/zeit/next.js/pull/8426#issuecomment-522801831）が原因ですが、最終的には、 /subdir/post/[id]要求しているときにNext.jsのルーターを混乱させていますそのようなファイルがディスク上に存在しない場合の

このスレッドには別の例、 https： //github.com/zeit/next.js/issues/4998#issuecomment -521189412がありとしてのみプレフィックスを付けます（簡略化）。

export default ({ children, href, as, ...rest }) => (
  <Link href={href} as={`${process.env.ASSET_PREFIX}${as}`} {...rest}>
    {children}
  </Link>
);

しかし、それはブラウザでこのエラーをスローします：

<Link>のas値は、 href値と互換性がありません。 これは無効です。

これはhttps://github.com/zeit/next.js/issues/7488で報告されている問題

結局のところ、 basePathようなものがサポートされるまで、解決策はないと思います。喜んでお手伝いさせていただきます。

@borekb数回前に述べたように、私も支援する準備ができています。 これまでに見たすべての回避策は、問題の一部のみを解決します。 現在、basePathを実装する本番環境でnext.jsのフォークを使用しています。

この提案を廃止する新しいAPIを間もなく導入する予定です。

@timそれはまだhttps://github.com/zeit/next.js/issues/7329

ところで。 明日はちょうど1年でこの号を開きました🎉

比較的ワイルドなアイデアの1つは、 src/pagesようなページを作成し、それらを適切な場所にシンボリックリンクすることです。 例えば：

• myapp.example.comにデプロイするにsrc/pagesをpagesシンボリックリンクします
• example.com/myappにデプロイするにsrc/pagesをpages/myappシンボリックリンクします

カスタムの<Link>コンポーネントとassetPrefixを組み合わせると、機能する可能性がありますが、試す勇気がありません😄。

それに関する更新はありますか？

basePathサポートに進展はありますか？ :)

@nicholasbraun

これで、リンククリックまたはルータープッシュイベントごとに、ページがfrowning_faceをリロードします。

私はこの問題を抱えていましたが、リンクで「as」パラメータを使用して修正したため、リンクは内部ファイルを指しますが、「as」はパスに関連しています
例えば：
<Link href={"/${item.link}"} as={"./${item.link}"}>

あなたは私の日を救った！ :)））

私はRouter.push(`/route`, `${process.env.BASE_PATH}route`);でも同じことをしています

@nicholasbraun

これで、リンククリックまたはルータープッシュイベントごとに、ページがリロードされます☹️

私はこの問題を抱えていましたが、リンクで「as」パラメータを使用して修正したため、リンクは内部ファイルを指しますが、「as」はパスに関連しています
例えば：
<Link href={"/${item.link}"} as={"./${item.link}"}>

このソリューションは、次の9ファイルベースのルーティングでは機能しません。 /route/[id] 、 ${process.env.BASE_PATH}/route${id}はこのエラーをスロー

このコメントは問題を非常によく説明しています。

私は数人の人々がここでの解決策がプリフェッチをどのように壊すかについて議論するのを見ましたが。 私たちにとって、もう1つの重要な問題があります。

next9では、 href assetPrefixを使用すると、 next常にサーバールートを実行します。 私はこの号でそれが起こっていることをデモする複製リポジトリを作成しました。

これは、すべてのルートで再作成されるため、基本的にApolloクライアントキャッシュを破壊します。

実装は、assetPrefixのない基になるページhrefを次のルートhref （assetPrefixを含む）と比較していると思います-結果として深いルートになります。

たとえば、href /prefix/page （基になるページは/page ）を使用していて、次のhrefルートが/prefix/page/[id] （プレフィックスがないと404になるため）これは完全に異なるルートであり、浅いルートは不可能です。

エクスプレスルートでその分で回避策を調べる

使用時 basePathであるhref小道具を持つコンポーネントでは、プリフェッチが機能していません。
PLZはbasePathとプリフェッチをサポートしています。

私は本当にこれを使うことができました。 単一のサーバーソースから複数のアプリを実行していて、それぞれが独自のweb/appX/{next project files}分かれています。 basePathをより細かく制御できると便利です。 今のところ回避策を見つけましたが、あまりきれいではありません。

静的エクスポートにもbasePathが必要です😊

仕事の成功のようです👏

{
  experimental:{
    basePath: '/some/dir',
  }
}

残念ながら、これは私たちにとってかなり悪い制限です:(

すべてのアプリがリバースプロキシの背後にあるため、パスにプレフィックスを付ける必要があります（以下の例では、これは/auction-resultsプレフィックスです）

すでにassetPrefixプレフィックスを使用しています。これにより、アプリはサーバー側のリクエストに対して正常に実行できます。
例： mydomain.com/auction-results/ような高速ルーティングを使用することで正常に機能します。

router.get(`/${appPrefix}/`, (req, res) => {
  nextApp.render(req, res, '/national', req.params);
});

しかし、 next/link介してクライアント側のナビゲーションを実行しようとすると、たとえば次のようになります。

ここで、 /auction-resultsはアプリケーションのプレフィックスであり、 /nationalは~pages/national

<Link href="/national" as="/auction-results/">
  <a>Goto National Page</a>
</Link>

これは何もしません（ゴーストクリック）

全ページ更新リンクを持つことは理想的とは言えません。

私がこれを手伝うことができる方法があれば私はしたいです

これに関する更新...昨年この頃、私はこの問題に遭遇しました。 1年後、私は新しいアプリに取り組んでおり、昨年と同じ回避策を実行する必要があります...「本番環境に対応した」reactfwにはちょっと憂慮すべきです。 ベースパスはバニラ機能である必要があります。

これに関する更新...昨年この頃、私はこの問題に遭遇しました。 1年後、私は新しいアプリに取り組んでおり、昨年と同じ回避策を実行する必要があります...「本番環境に対応した」reactfwにはちょっと憂慮すべきです。 ベースパスはバニラ機能である必要があります。

これを投稿して何を期待しているのかわかりません。

Next.jsは私のチーム（5人）によってフルタイムで作業されており、同時に多くの機能に取り組んでいます。 昨年、私たちはこれらに取り組みました：

• https://nextjs.org/blog/next-9
• https://nextjs.org/blog/next-9-0-7
• https://nextjs.org/blog/next-9-1
• https://nextjs.org/blog/next-9-1-7
• https://nextjs.org/blog/next-9-2
• https://nextjs.org/blog/next-9-3

Next.jsアプリケーション（新規および既存）を効果的に大幅に小さく、高速にし、スケーラブルにします。

機能に対する「賛成」を表明したい場合は、それが可能です。 最初のスレッドで👍機能を使用します。

basePathが組み込み機能であるべきだということには間違いなく同意します。 それはすでにロードマップ上にあり、私は最初のPRを書きました。これは、スレッドを読み返すことで確認できます。

PRは次のとおりです： https ：

この機能の実現に経済的に貢献したい場合は、 enterprise @ vercel.comまでお気軽にご連絡ください。

これのステータスは何ですか？ 私たちは本当にこれに依存しています：/

@Sletheren basePathのサポートは現在実験的なものであり、owmのリスクで使用してください。

cf. https://github.com/zeit/next.js/pull/9872

@Sletheren basePathのサポートは現在実験的なものであり、自己責任で使用してください。

cf. ＃9872

@martpie私はすでにそれを見ましたが、のために。 私の場合、 basePathは1つだけではなく、複数のbasePathになる可能性があります。これは、さまざまな「URL」を介してアプリを提供し、ビルド時にbasePathを設定することはオプションではないためです（単一の文字列ではなくパスの配列をサポートするため）

@timneutkens更新していただきありがとうございます。 別のアップデートを提供していただけませんか。 これは私たちにとって重要な機能であり、知る必要があります...

1. これは企業のみになりますか（企業の営業に連絡することへの言及は、いくらかの苛立ちを引き起こしました）？

2. PRによると、ロードマップ上にあるようですが、二度と削除されることはありません。 不自由なオープンソースバージョンや、ランダムな営業担当者と任意の価格について数週間交渉した後、完全にサポートされた別のバージョンなど、今後数か月で驚きを感じることなく、この機能を今すぐ構築しても安全かどうかを示すことができますか？

皆さんは多くの機能に取り組んでおり、誰もが優先順位を持っていることを理解していますが、さらに小さなセットアップでもプロキシする必要があります。次に、複数のインスタンスを実行し、サービスごとに専用のbasePath割り当てます。 Nextで複数のサービスの構築を開始する前に、この機能が完全なオープンソースとして利用可能になる可能性を知る必要があります。 そうでなければ、Nextにさらに時間を投資するのはリスクが高すぎます。

ご理解とご意見をお寄せいただきありがとうございます。

FWIW、私はそれが機能するようになりました、そして他の人のために：

これをnext.config.js入れてください：

module.exports = {
  experimental: {
    basePath: '/custom',
  },
}

次に、サーバーを再起動し、Webサーバーミドルウェアを適切にセットアップする必要がありました。

カスタムパスを介してすべてのリクエストをキャッチします。 app.use('/custom', (req, res...) => { ...そして（これは重要でした）Nextが実行されているシステムのURLにプロキシする必要があります（したがって、コンテナオーケストレーションの内部アドレスと、 http-proxyを使用する場合はそれぞれのパスを使用します） http-proxy =>例： ... target: 'http://next:3000/custom ）、カスタムパスのないホストだけではありません。 http-proxy-middlewareを使用する場合、これは必要ありません。

かなり大丈夫だと思います。この機能にEEライセンスが必要ないことを願っています。 あなたのチームがこの機能を成熟させるために助けが必要な場合は、plsが私たちに知らせてください、多分私たちは助けることができます！

編集：Nextのプロダクションモードでもこれを試したところ、うまくいくようです。

@timneutkens更新していただきありがとうございます。 別のアップデートを提供していただけませんか。 これは私たちにとって重要な機能であり、知る必要があります...

1. これは企業のみになりますか（企業の営業に連絡することへの言及は、いくらかの苛立ちを引き起こしました）？
2. PRによると、ロードマップ上にあるようですが、二度と削除されることはありません。 不自由なオープンソースバージョンや、ランダムな営業担当者と任意の価格について数週間交渉した後、完全にサポートされた別のバージョンなど、今後数か月で驚きを感じることなく、この機能を今すぐ構築しても安全かどうかを示すことができますか？

皆さんは多くの機能に取り組んでおり、誰もが優先順位を持っていることを理解していますが、さらに小さなセットアップでもプロキシする必要があります。次に、複数のインスタンスを実行し、サービスごとに専用のbasePath割り当てます。 Nextで複数のサービスの構築を開始する前に、この機能が完全なオープンソースとして利用可能になる可能性を知る必要があります。 そうでなければ、Nextにさらに時間を投資するのはリスクが高すぎます。

ご理解とご意見をお寄せいただきありがとうございます。

@ pe-sあなたは私の投稿を誤解していると思います。

現在のところ、「エンタープライズNext.jsバージョン」はありません。 私は、外部企業がこのような機能をより短い期間で構築するためのコンサルティングにお金を払うために手を差し伸べた多くの機会について言及していました。 たとえば、ゾーンのサポートはTruliaと共同で構築されました。

この機能はまだ作業中であり、ロードマップ上にあります。 Next.jsのエンタープライズバージョンはないと言ったように、作業中のすべての機能はオープンソースです。 私は連絡を呼び、したがって、なぜけれども我々はロードマップ上でインパクトのある作品の複数の優先順位を持っている[email protected]をあなたはNext.js.のエンタープライズサポートを議論するとすぐ/可能な限り、この機能が必要な場合

@timneutkens txは、迅速な対応と素晴らしい対応を提供します。 次に、すべてを入力できます:)
これからもいい結果を出し続けてください！

ベースパスのサポートは現在next@canaryおり、実験的なものではありません。 まもなく安定したチャンネルになります。

私はこれにかなり遅れていますが、これを手動で処理する代わりに、実際のHTML <base>を使用することを検討しましたか？

ベースパスのサポートは現在next@canaryおり、実験的なものではありません。 まもなく安定したチャンネルになります。

@timneutkens 、この追加に感謝します。 非実験的なbasePathサポートがいつ正式にリリースされるか知っていますか？

また、basePathを設定すると、アセット（パブリックフォルダーにあります）が期待どおりに適切なURLに提供されます。 ただし、コードでそれらを参照する場合は、ベースパスをsrcに手動で追加する必要があります。そうしないと、通常のパスから参照されるためです。 これはbasePathの予想される使用法ですか？ また、assetPrefixを使用してみましたが、コードに影響がありませんでした。

例：

1. next v9.4.5-canary.24
2. next.config.jsでbasePathを/alertsに設定：

const basePath = '/alerts';
module.exports = {
  basePath: basePath,
  env: {
    BASE_PATH: basePath,
  },
};

1. public/images/example.pngにある資産
2. 反応コンポーネントでのアセットの使用例：

const ExampleImage = () => (
  <img src={`${process.env.BASE_PATH}/images/example.png`} />
);

私のテストでは、アセットのURLを更新していません。

最新のカナリアをインストールしました：
npm install [email protected]

next.config.js

const isProd = process.env.NODE_ENV === 'production';

module.exports = {
  basePath: isProd ? '/example' : ''
}

すべてのページとリンクが正しく読み込まれます。
http：// localhost ：3000 / example / posts / pre-rendering
http：// localhost ：3000 / example / posts / ssg-ssr
http：// localhost ：3000 / example / posts / pre-rendering

ただし、画像、ファビコンなどはマッピングされていません。
http：// localhost ：3000 / favicon.ico 404
http：// localhost ：3000 / images / profile.jpg 404

誰かがこれをテストしましたか？ また、assetPrefixを使用してみましたが、それも機能しませんでした。

さらに、私は混乱していますが、これに組み込みのブラウザ機能を使用してみませんか？
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base

@kmturleyも同様にあなたの側でこれを調べてくれてありがとう。 それが私だけではないことを知ってうれしいです。
@timneutkens 、この問題を

画像に手動でプレフィックスを付ける必要があります。 basePathは次を使用して取得できます

const {basePath} = useRouter()

https://nextjs.org/docs/api-reference/next.config.js/cdn-support-with-asset-prefix

Next.jsは、ロードするスクリプトでプレフィックスを自動的に使用しますが、これはパブリックフォルダーにはまったく影響しません。

/ public内のファイルにリンクする方法は複数あることに気づきました。 例： <img/> <link/> ..。
これが、それぞれにbasePathを手動で指定する必要がある理由ですか？

以下のようなコンポーネントが利用可能であれば、時間を節約し、多くの人の混乱を減らすことができると思いますか？

<WithinBasePath>
  {/* automatically fixes the path with basePath */}
  <img src="/logo.png" />
</WithinBasePath>

私はこれが適切であるとは本当に思いませんが、これは私が意味したことです。

// src/components/WithinBasePath/index.tsx

import React from "react"
import path from "path"
import { useRouter } from "next/router"
interface Props {}

const WithinBasePath: React.FC<Props> = (props) => {
  const { basePath } = useRouter()
  const children = [props.children].flatMap((c) => c) as React.ReactElement[]
  return (
    <>
      {children.map((child, key) => {
        let newChild = null

        switch (child.type) {
          case "img":
            newChild = React.createElement(child.type, {
              ...child.props,
              src: path.join(basePath, child.props.src),
              key,
            })
            break
          case "link":
            newChild = React.createElement(child.type, {
              ...child.props,
              href: path.join(basePath, child.props.href),
              key,
            })
            break
          default:
            newChild = React.createElement(child.type, {
              ...child.props,
              key,
            })
        }
        return newChild
      })}
    </>
  )
}
export default WithinBasePath

// pages/test.tsx

import React from "react"
import WithinBasePath from "@src/components/WithinBasePath"
interface Props {}

const test: React.FC<Props> = (props) => {
  return (
    <WithinBasePath>
      <img src="/123.jpg" />
      <link href="/abc.jpg" />
      <div>other element</div>
    </WithinBasePath>
  )
}
export default test

フックであるconst {basePath} = useRouter()を使用してクラスとコンポーネントを操作しようとしている場合は、次のエラーが発生します。

無効なフックコール警告

https://reactjs.org/warnings/invalid-hook-call-warning.html

次を使用して動作させることができます。

import { withRouter, Router } from 'next/router'

class Example extends Component<{router: Router}, {router: Router}> {
  constructor(props) {
    super(props)
    this.state = {
      router: props.router
    }
  }
  render() {
    return (
      <Layout home>
        <Head><title>Example title</title></Head>
        <img src={`${this.state.router.basePath}/images/creators.jpg`} />
      </Layout>
    )
  }
}
export default withRouter(Example)

マークダウンでbasePathを使用する場合は、文字列内で検索と置換を行う必要があるようです。

const content = this.state.doc.content.replace('/docs', `${this.state.router.basePath}/docs`);
return (
<Layout>
  <Container docs={this.state.allDocs}>
    <h1>{this.state.doc.title}</h1>
    <div
      className={markdownStyles['markdown']}
      dangerouslySetInnerHTML={{ __html: content }}
    />
  </Container>
</Layout>
)

画像に手動でプレフィックスを付ける必要があります。 basePathは次を使用して取得できます

const {basePath} = useRouter()

ただし、このソリューションでは、cssまたはscssファイルにインポートされた画像は考慮されません。 cssまたはscssファイル内からアセットをインポートするときにベースパスを設定する方法の解決策はありますか？
このソリューションでは、すべての画像がimgタグ、インラインスタイル、またはスタイルタグのいずれかを介してインポートされるようにする必要があります。 スタイルが分割されて複数の場所に実装されるため、理想的ではありません。

@peetjvvこれは、CSSでbasePathsというプレフィックスが付いたアセットを使用するための次善のソリューションです。 _app.tsxに<CSSVariables>コンポーネントを作成、インポート、追加します。これにより、CSS変数を含むグローバルなインライン<style>要素が挿入され、スタイルシート全体で使用できるようになります。

たとえば、 <body>ビルドおよび

<style>
:root {
      --asset-url: url("${basePath}/img/asset.png");
}
</style>

そのbasePathを取得するには、 withRouterを使用した@kmturleyのアプローチを使用します。
そのコンポーネントは次のようになります。

import { withRouter, Router } from "next/router";
import { Component } from "react";

export interface IProps {
  router: Router;
}

class CSSVariables extends Component<IProps> {
  render() {
    const basePath = this.props.router.basePath;
    const prefixedPath = (path) => `${basePath}${path}`;
    const cssString = (value) => `\"${value}\"`;
    const cssURL = (value) => `url(${value})`;
    const cssVariable = (key, value) => `--${key}: ${value};`;
    const cssVariables = (variables) => Object.entries(variables)
      .map((entry) => cssVariable(entry[0], entry[1]))
      .join("\n");
    const cssRootVariables = (variables) => `:root {
      ${cssVariables(variables)}
    }`;

    const variables = {
      "asset-url": cssURL(
        cssString(prefixedPath("/img/asset.png"))
      ),
    };

    return (
      <style
        dangerouslySetInnerHTML={{
          __html: cssRootVariables(variables),
        }}
      />
    );
  }
}

export default withRouter(CSSVariables);