Angular 8 – 小さなバンドル、CLI API、エコシステム準拠 – Angular Blog日本語訳

Angular 9 も先ほど RC4 がリリースされ、いよいよ正式版のリリースもあとわずかというところまで迫ってきています。今さらではありますが、Angular 9 のリリースに備えて、復習を兼ねて Angular Blog の Angular 8 リリース時の記事を翻訳してみました。

Stephen Fluin May 29

The 8.0.0 release of Angular is here! This is a major release spanning the entire platform, including the framework, Angular Material, and the CLI with synchronized major versions. This release improves application startup time on modern browsers, provides new APIs for tapping into the CLI, and aligns Angular to the ecosystem and more web standards.

Angular 8.0.0 がリリースされました。フレームワーク、Angular Material、CLIの同じバージョンを含むプラットフォーム全体を通したメジャーリリースです。このリリースでは、モダンブラウザでのアプリケーションの起動時間を改善し、CLIを利用するための新しい API を提供し、Angular をエコシステムやより多くの Web 標準に準拠させました。

Photo by Angular TPM, Manu Murthy

How to update to version 8 – バージョン 8 へのアップデート方法について

Visit for detailed information and guidance. For most developers, one command should take care of this update:

詳細な情報やガイダンスについては、 でご確認ください。ほとんどの開発者は、このコマンド一つでアップデートができるでしょう。

$ ng update @angular/cli @angular/core

Differential Loading by Default – デフォルトで Differential Loading が機能します

Differential loading is a process by which the browser chooses between modern or legacy JavaScript based on its own capabilities. We now take advantage of this by default by performing a modern build (es2015) and a legacy build (es5) of your application. When users load your application, they’ll automatically get the bundle they need.

Differential loading は、ブラウザに、その互換性に基づいてモダンな JavaScript なのか、レガシー な JavaScript なのか選択させる処理です。あなたの Angular アプリケーションのモダンビルド(es2015)とレガシービルド(es5)を実行させることによって、この機能をデフォルトで使用できるようになっています。ユーザーが あなたのアプリケーションをロードした時、自動的に必要なバンドルが選択されるようになります。

If you use ng update, we update your tsconfig.json for you to take advantage of this. Our CLI looks at the target JS level in your tsconfig.json to determine whether or not to take advantage of Differential Loading.

ng update を使ってアップデートを行えば、この機能を使用できるように自動で tsconfig.json が更新されます。CLI は、Differential Loading を使用するかどうかを決定するために、tsconfig.jsontarget に指定してある JS のレベルを見ます。

  "compilerOptions": {
  "module": "esnext",
  "moduleResolution": "node",
  "target": "es2015",

When target is set to es2015, we generate and label two bundles.

targetes2015 と指定してあれば、2 つのバンドルを生成し、ラベルをつけます。

At runtime, the browser uses attributes on the script tag to load the right bundle.

ランタイムにおいて、ブラウザは適切なバンドルをロードするために script タグの属性を使います。

<script type="module" src="…"> // Modern JS

<script nomodule src="…"> // Legacy JS

On we saved over 40kB of initial bundle size for modern browsers. From the community we’ve heard that applications generally save 7–20% of their bundle size, depending on the amount of modern JavaScript features they take advantage of. において、我々はモダンブラウザの初期バンドルサイズを 40kb 以上も抑えることができました。コミュニティからもバンドルサイズをだいたい 7〜20% (彼らが使用するモダンな JavaScript の機能の量に応じて)抑えることができたという声をいただきました。

The bundle size on
The bundle size on shrunk by about 41Kb

Learn more about differential loading.

differential loading についての詳細はこちらです。

Route Configurations use Dynamic Imports – ルートの設定に Dynamic Imports を使用します

We highly recommend you lazily load parts of your application using the router. This is accomplished by using the loadChildren key in your route configuration.

ルーターを使用してアプリケーションの一部を遅延ロードすることを強くお勧めします。これは、ルートの設定で、loadChildren キーを使用することで実現できます。

Previously this looked like:


  path: '/admin',
  loadChildren: './admin/admin.module#AdminModule',

This syntax was custom to Angular and built into our toolchain. With version 8 we’re migrating to the industry standard dynamic imports.

この構文は、Angularのカスタム構文であり、ツールチェインに組み込まれていました。バージョン 8 で、業界標準の dynamic import に移行しました。

Now this will look like:


  path: `/admin`,
  loadChildren: () => import(`./admin/admin.module`).then(m => m.AdminModule),

This will improve the support from editors like VSCode and WebStorm who will now be able to understand and validate these imports for you.

これにより、VSCodeWebStorm のようなエディタのサポートが改善され、インポートが理解され、バリデートされるようになるでしょう。

If you use ng update, we’ll update your code automatically to use the new best practice.

ng update を使ってアップデートを行えば、この新しいベストプラクティスを自動的に使えるようになります。

Builder APIs in the CLI – CLI の ビルダーAPI

In the same way that Schematics allow you to tap into ng new ng generate ng add and ng update, we’ve released new Builder APIs that allow you to tap into ng build ng test and ng run to perform processes like build and deployment.

Schematics によって ng newng generateng addng update を利用できるようになったのと同じように、ビルドやデプロイのような処理を実行するための ng buildng testng run を使えるようになる新しいビルド用の API をリリースしました。

Check out our blog post on these new APIs.

これらの新しい API についてのブログ記事でご確認ください。

Or read the API documentation.

それから、API ドキュメントに目を通してください。

We’ve also been working with cloud providers to begin taking advantage of these APIs. Today you can try the latest version of AngularFire, which adds a deploy command, making build & deploy to Firebase easier than ever:

さらに、クラウドのプロバイダと協力して、これらの API を利用できるようにしました。今日から AngularFire の最新バージョンをお試しいただけます。Firebase へのビルドとデプロイをこれまでになく簡単にしてくれる deploy コマンドが追加されています。

$ ng add @angular/fire
$ ng run my-app:deploy

Once installed, this deployment command will both build and deploy your application in the way recommended by AngularFire.

一度インストールされると、このデプロイ用のコマンドは、AngularFire によってオススメされている方法であなたのアプリケーションのビルドとデプロイを行ってくれます。

Workspace APIs in the CLI – CLI の Workspace API

Previously developers using Schematics had to manually open and modify their angular.json to make changes to the workspace configuration. With 8.0, we’re introducing a new API to make it easier to read and modify this file.

これまで schematics を使っている開発者は、ワークスペースの設定を変更する際は手動で angular.json ファイルを開いて修正しなければいけませんでした。バージョン 8.0 では、このファイルをより簡単に読んで編集できる新しい API を導入しています。

Read more about the available Workspace APIs.

ワークスペース API についての詳細はこちらでご確認ください。

Web Worker Support – Web Worker をサポート

Web workers are a great way to speed up your application if you do any sort of cpu-intensive processing. Web workers allow you to offload work to a background thread, such as image or video manipulation. We use web workers on for in-app search indexing.

Web Worker は、CPU を集中的に使用する処理を行う場合に、アプリケーションを高速にするすばらしい方法です。Web Worker は、画像や映像の操作のようなバックグランドのスレッドのためのオフロード処理を可能にしてくれます。 でアプリ内検索のインデクシングを行うために Web Worker を使用しています。

You can now generate new web workers from the CLI. To add a worker to your project, you can run:

CLI から新しい Web Worker を生成できるようになりました。プロジェクトにワーカーを追加するには、以下を実行してください。

$ ng generate webWorker my-worker

Once you have a web worker, you can use it normally in your application, and the CLI will be able to bundle and code split it correctly:

一度 Web Worker を生成したら、常にアプリケーションで利用できるようになります。CLI は適切にそれをバンドルおよびコード分割できるようになります。

const worker = new Worker(`./my-worker.worker`, { type: `module` });

Read more about web workers in the Angular CLI.

Angular CLI における Web Worker についての詳細はこちらをお読みください。

AngularJS Migration Improvements – AngularJSからの移行を改善

If you use the $location service in an AngularJS application, Angular now provides a LocationUpgradeModule that enables a unified location service that shifts responsibilities from the AngularJS $location service to the Angular Location Service. This should improve the lives of applications using ngUpgrade who need routing in both the AngularJS and Angular part of their application.

AngularJS アプリケーションで $location service を使用している方に対して、Angular の LocationUpgradeModule が使えるようになりました。これにより、AngularJS の $location service から Angular の Location Service に責務を移行する統合された location service を利用可能にします。これにより アプリケーションの AngularJS と Angular の両部分でルーティングを必要とする ngUpgrade を使用しているアプリケーションの寿命を改善されるでしょう。

Read more about the Unified Angular Location Service.

統合された Angular Location Service についての詳細はこちらをお読みください。

We’ve also documented best practices around lazy loading parts of your AngularJS application from Angular, making it easier to migrate the most commonly used features first, and only loading AngularJS for a subset of your application.

我々はさらに Angular から AngularJS アプリケーションの一部を遅延ロードすることに関してベストプラクティスを文書化しました。これは、まず最初に一般的に使用されるほとんどの機能をより簡単に移行できるようにし、アプリケーションのサブセットのために AngularJS だけをロードするということです。

Read more about Lazy Loading AngularJS.

AngularJS の遅延ロードについての詳細はこちらをお読みください。

New Deprecation Guide – 新たな非推奨ガイド

We are committed to maintaining Semantic Versioning and a high degree of stability even across major versions. For our public API, we are committed to supporting features for N+2 releases. This means that a feature that is deprecated in 8.1 will keep working in the following two major releases (9 and 10). For example, we are deprecating platform-webworker in version 8.

我々は、メジャーバージョン間でも、セマンティックバージョニングと高度な安定性の維持に取り組んでいます。パブリックな API に関しては、N + 2 リリース間、機能をサポートすることを約束しています。8.1 で非推奨となった機能は、次の 2 つのメジャーリリース(9 と 10)でも動き続けるということを意味しています。例えば、バージョン 8 では platform-webworker を非推奨にしています。

We are making it easier to find deprecations and removals in Angular. For a comprehensive list of all deprecations, see the new Deprecation Guide.

Anuglar で非推奨または削除となってものを探しやすくするようにしました。すべての非推奨項目の包括的なリストに関しては、新しい非推奨ガイドを見てください。

Ivy & Bazel

We know there’s lots of excitement for our forthcoming opt-in previews. We’ll be providing individual updates on these next week on this blog, so stay tuned!


Contributors and Collaborators – コントリビュータとコラボレータ

A special thanks to Manfred Steyer for contributing to Differential Loading, Craig Spence to Dynamic Import support, Jason Miller to Web Worker bundling support. This release was brought to you by 286 contributors:

Differential Loading に対して貢献してくれた Manfred Steyer、 Dynamic Import のサポートに対して貢献してくれた Craig Spence、Web Worker の開発のサポートに対して貢献してくれた Jason Miller に感謝します。このリリースは、286 人のコントリビュータによってもたらされたことをお伝えします。


以上、Angular公式ブログの記事『Version 8 of Angular — Smaller bundles, CLI APIs, and alignment with the ecosystem』の翻訳でした。原文も載せていますので、わかりにくい部分があれば、そちらも合わせてお読みください。



  • 必須