Lang x Lang

Version 12

version 12 にアップグレードするには、次のコマンドを実行します:

Terminal
npm i next@12 react@17 react-dom@17 eslint-config-next@12
Terminal
yarn add next@12 react@17 react-dom@17 eslint-config-next@12
Terminal
pnpm up next@12 react@17 react-dom@17 eslint-config-next@12
Terminal
bun add next@12 react@17 react-dom@17 eslint-config-next@12

Good to know: TypeScript を使用している場合、@types/react@types/react-domもそれぞれ対応するバージョンにアップグレードしてください。

12.2 へのアップグレード

Middleware - もし12.2より前に Middleware を使用していた場合、詳細な情報についてはアップグレードガイドをご覧ください。

12.0 へのアップグレード

最低の Node.js Version - 最低 Node.js version は12.0.0から12.22.0に引き上げられました。これがネイティブ ES Modules サポートを持つ最初の version の Node.js です。

最低限必要な React Version - 最低限必要な React version は 17.0.2です。アップグレードするためには、ターミナルで以下のコマンドを実行できます。

Terminal
npm install react@latest react-dom@latest

yarn add react@latest react-dom@latest

pnpm update react@latest react-dom@latest

bun add react@latest react-dom@latest

SWC が Babel を置き換える

Next.js は現在、JavaScript/TypeScript をコンパイルするために Rust ベースの compilerSWC を使用しています。この新しい compiler は、個々のファイルをコンパイルする際に Babel よりも最大 17 倍高速で、FastRefresh に対しては最大 5 倍高速です。

Next.js は、カスタムの Babel 設定を持つアプリケーションと完全に後方互換性を提供します。getStaticProps / getStaticPaths / getServerSidePropsの styled-jsx や tree-shaking のように Next.js が default で扱うすべての変換は Rust に移植されています。

アプリケーションがカスタムの Babel 設定を持っている場合、Next.js は自動的に SWC の使用をオプトアウトし、Javascript / Typescript のコンパイルに Babel を同じように使用するように Next.js 11 で使用されていました。

現在、Babel のカスタム変換を必要とする多くの外部ライブラリとの統合は、近い将来、Rust ベースの SWC 変換に移植される予定です。これには以下が含まれますが、それに限定されません:

  • Styled Components
  • Emotion
  • Relay

SWC を採用するのに役立つ変換を優先するために、あなたの .babelrcこのフィードバック thread に提供してください。

SWC が minification のための Terser を置き換え

next.config.jsのフラグを使用して、Terser を SWC に置き換えて、 JavaScript を最大 7 倍速く最小化するオプトインが可能です:

next.config.js
module.exports = {
  swcMinify: true,
}

SWC を使用した Minification は、それが Next.js12.1 で default になる前に、より多くの実際の Next.js アプリケーションでテストできるように、オプトインフラグです。minification に関するフィードバックがある場合は、このフィードバックの thread にコメントを残してください。

styled-jsx CSS 解析の改善

我々は Rust ベースの compiler の上に、styled-jsx Babel transform のために使用されるものに基づく新たな CSS パーサーを実装しました。この新パーサーは CSS の取り扱いを改善し、以前は見逃されがちだった無効な CSS の使用に対して error を出すようになり、予期しない挙動を引き起こすことがありました。

この変更のため、無効な CSS は、development とnext buildの間に error をスローします。この変更は、styled-jsx の使用にのみ影響を与えます。

next/image はラッピング要素を変更しました

next/imageは今、<img><div>の代わりに<span>内でレンダリングします。

もしもあなたのアプリケーションが、.container spanのような特定の CSS をターゲットにしている場合、Next.js 12 にアップグレードすると、<Image> component 内のラッピング要素が誤ってマッチする可能性があります。これを避けるには、セレクタを .container span.item のように特定のクラスに限定し、関連する component をその className で更新することで対処できます。たとえば、<span className="item" /> のようにします。

あなたのアプリケーションが特定の CSS を next/image <div> タグに適用している場合、たとえば .container div など、それはもう一致しないかもしれません。セレクター .container span を更新するか、できれば、新しい <div className="wrapper"><Image> component に追加して、その代わりに target を設定してみてください。たとえば .container .wrapper のような形になります。

classNameプロップは変更されておらず、基本となる<img>要素に引き続き渡されます。

詳細については、ドキュメンテーションをご覧ください。

HMR 接続は現在、WebSocket を使用しています

以前、Next.js は、HMR イベントを受信するためにserver-sent events 接続を使用していました。Next.js12 は現在、WebSocket 接続を使用しています。

一部のケースでは、 Next.js dev server へのリクエストをプロキシする際に、 request のアップグレードが正しく処理されることを確認する必要があります。たとえば、nginxでは次の構成を追加する必要があります:

location /_next/webpack-hmr {
    proxy_pass http://localhost:3000/_next/webpack-hmr;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

もし Apache(2.x)を使っているなら、以下の設定を追加することで、server にウェブソケットを有効にすることができます。port、host の名前、そして server の名前を確認してください。

<VirtualHost *:443>
 # ServerName yourwebsite.local
 ServerName "${WEBSITE_SERVER_NAME}"
 ProxyPass / http://localhost:3000/
 ProxyPassReverse / http://localhost:3000/
 # Next.js 12 uses websocket
 <Location /_next/webpack-hmr>
    RewriteEngine On
    RewriteCond %{QUERY_STRING} transport=websocket [NC]
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteRule /(.*) ws://localhost:3000/_next/webpack-hmr/$1 [P,L]
    ProxyPass ws://localhost:3000/_next/webpack-hmr retry=0 timeout=30
    ProxyPassReverse ws://localhost:3000/_next/webpack-hmr
 </Location>
</VirtualHost>

カスタム server の場合、例えばexpressのようなものでは、request が正しく渡されることを確保するために、app.allを使用する必要があるかもしれません。例えば:

app.all("/_next/webpack-hmr", (req, res) => {
  nextjsRequestHandler(req, res);
});

Webpack 4 のサポートは削除されました

すでに webpack5 を使用している場合は、このセクションをスキップできます。

Next.js は、Next.js11 のコンパイルのための default として webpack5 を採用しました。webpack 5 のアップグレードドキュメンテーションで伝えられた通り、Next.js 12 は webpack 4 のサポートを削除します。

あなたのアプリケーションがまだ webpack 4 を opt-out フラグを使って使用している場合、今後、error が表示され、webpack 5 のアップグレードドキュメンテーションへのリンクが表示されます。

target オプションは廃止予定です

next.config.jstargetがない場合、このセクションをスキップすることができます。

target オプションは、ページの実行に必要な依存関係を追跡するための組み込みサポートを優先するため、非推奨となりました。

next buildの間に、Next.js は自動的に各ページとその依存関係を追跡し、アプリケーションの production version をデプロイするために必要なすべてのファイルを決定します。

あなたが現在 target オプションを serverless に設定して使っている場合は、新しいアウトプットを活用する方法についての文書をご覧ください。

当社サイトでは、Cookie を使用しています。各規約をご確認の上ご利用ください:
Cookie Policy, Privacy Policy および Terms of Use