Next.js 6.1

2018年6月27日水曜日

投稿者: Tim Neutkens @ timneutkens

本日、プロダクション対応のNext.js 6.1をリリースできることを誇りに思います。主な機能は以下の通りです：

• ホットリロードの信頼性向上
• コードベースの改善
• Next.js codemods

Next.js 6.1のリリースに加えて、nextjs.orgがオープンソース化されたことを発表できることを嬉しく思います。

ホットリロードの信頼性向上

Next.js 6.1以前のバージョンでは、Next.jsはユーザーに代わってreact-hot-loaderを実装していました。このライブラリはホットリロード間でReactの状態を保持します。その際、react-hot-loaderはReactにいくつかの非標準的な動作を追加します。例えば、shouldComponentUpdateを無視し、要素タイプが実際のReactコンポーネントではなくプロキシコンポーネントになってしまいます。

Next.jsを可能な限りデフォルトのReactに近づけるため、react-hot-loaderを依存関係から削除しました。これにより、開発モードとプロダクションモードの動作がより近くなります。

なお、Next.jsのホットリロード機能は削除されていません。ホットリロードは常にNext.js内部で処理されています。

Typescriptやその他のカスタム拡張子のホットリロード

デフォルトでは、Next.jsは自動的にpagesディレクトリ内の.jsまたは.jsxファイルを探してルートを定義します。Next.js 5でuniversal webpackが導入されたことで、compile-to-jsのトップレベルページを持つことが可能になりました。良い例がTypescriptで、.tsと.tsxを使用します。

pageExtensionsは、Next.jsプラグインがページとして考慮すべき拡張子を定義できるようにすることを目的としたnext.config.jsの設定キーです。例えば、@zeit/next-typescriptは.tsと.tsxを定義し、@zeit/next-mdxはトップレベルの.mdxページを持つ方法を文書化しています。

以前、pageExtensionsを実装する際、Next.jsプラグインはホットリロードに使用されるhot-self-accept-loaderを実装する必要がありました。これはもう必要ありません。pageExtensionsに拡張子を追加すると、hot-self-accept-loaderが自動的に適用されます。

コードベースの改善

最近、今後の機能への道筋を整えており、これには長期的にコード品質を向上させるいくつかの内部変更が含まれています。

これらの変更の一つは、server/buildディレクトリがトップレベルのbuildに移動されたことです。これにより、新しい貢献者にとってwebpackとbabel設定を見つけやすくなります。

また、コードベース全体にFlow型を追加することにも注力しています。

ユーザーにとってより目に見える変更として、.next/distが.next/serverに名前変更されました。

• .nextディレクトリはビルド出力を保持します。例えば、next buildを実行すると、結果は.nextに保存されます
• プリレンダリングファイルは現在serverディレクトリにあります
• 同じ定数の出現箇所は共通ファイルconstants.jsに移動されました

Next.js codemods

Next.js 6.0がリリースされた際、ページコンポーネントに魔法のように注入されるurlプロパティは非推奨になりました。urlが廃止される理由は、物事を非常に予測可能で明示的にしたいからです。どこからともなく現れる魔法のurlプロパティは、その目標に役立ちません。

urlプロパティが持っていたのと同じプロパティを取得する推奨方法は、withRouterを使用することです：

// 古い方法
class Page extends React.Component {
  render() {
    const { url } = this.props;
    return <div>{url.pathname}</div>;
  }
}
export default Page;

Next.js 6以前のバージョンでurlを使用してpathnameにアクセスする方法

// 新しい方法
import { withRouter } from 'next/router';

class Page extends React.Component {
  render() {
    const { router } = this.props;
    return <div>{router.pathname}</div>;
  }
}
export default withRouter(Page);

Next.js 6以降のバージョンで、withRouterによって注入されるrouterを使用してpathnameにアクセスする方法

Next.jsアプリケーションのアップグレードパスをシンプルに保つことにコミットしているため、urlからwithRouterへの使用法を簡単にアップグレードする方法を作成することに着手しました。この取り組みの結果がnext-codemodです。これは、特定の非推奨機能を新しい使用法にアップグレードすることを、一つのコマンドを実行するだけで簡単にするcodemodのライブラリです。

最初に提供するcodemodは、urlが使用されていた多くのケースをwithRouterに自動的に変換するurl-to-withrouterです。

jscodeshift -t ./url-to-withrouter.js pages/**/*.js

これにより、urlの使用がwithRouterに変換されます。詳細はこちらをお読みください。

Next.jsへの貢献

Next.jsコミュニティは成長しており、Next.jsコアまたはexamplesに少なくとも1つのコミットを既に投稿した貢献者が450人以上います。

Next.jsに貢献する方法はたくさんあります：

• コミュニティに参加し、GitHubでアドバイスを提供する
• 一般的な使用例のexamplesに貢献する：examplesディレクトリ
• GitHubのgood first issueとhelp wantedラベルをチェックする

good first issueラベルの付いた30のオープンイシューがあり、新しい貢献者に貢献の機会を提供しています。

nextjs.orgのオープンソース化

nextjs.orgがオープンソース化されたことを発表できることを嬉しく思います。これにより、参考となるNext.js実装として機能し、問題や改善をプロジェクトに直接報告できるようになります。

今後の展望

信頼性とパフォーマンスを向上させるいくつかの新機能に取り組んでいます。以下にハイライトをいくつか紹介します：

Webpack 4

Webpack 4は多くの改善をもたらします：より良いコード分割、デフォルトで必要な設定の削減、そして最も重要なのはより高速なビルド時間です。200ページを超えるアプリで行った初期テストでは、next buildにかかる時間が平均100秒から70秒に短縮されました。2回目の実行（キャッシュあり）では、next buildは平均21秒でした。

サーバーレスNext.js

next startを独自のパッケージnext-serverに移行する準備として、段階的に変更を行っています。このパッケージは、インストールサイズと起動時間に対して大幅に最適化されます。これらの最適化は、リクエストごとまたは数リクエストごとにアプリの新しいインスタンスが実行される「サーバーレス」ユースケースに必要です。つまり、アプリケーションの「コールドスタート」を可能な限り高速になるよう最適化する必要があります。