Stephen Fluin Feb 7

The 9.0.0 release of Angular is here! This is a major release that spans the entire platform, including the framework, Angular Material, and the CLI. This release switches applications to the Ivy compiler and runtime by default, and introduces improved ways of testing components.

Angular 9.0.0 がリリースされました！フレームワーク、Angualr Material、Angular CLI を含むプラットフォーム全体に及ぶメジャーリリースです。このリリースでは、アプリケーションを Ivy コンパイラーとランタイムに切り替え、コンポーネントのテストの方法を改善しました。

This is one of the biggest updates to Angular we’ve made in the past 3 years, and we’re excited for all of the ways it empowers developers to build better applications and contribute to the Angular ecosystem.

今回のアップデートは Angular にとって、この 3 年間で最大のアップデートの一つとなり、我々は、今回リリースしたものすべてに興奮しています。これらは、開発者にとって、より良いアプリケーションを構築し、Angularエコシステムに貢献してくれるものとなるでしょう。

How to update to version 9 – Angular 9 へのアップデート方法

Visit update.angular.io for detailed information and guidance. To have the best update experience, we recommend you first update to the final release of Angular 8.

update.angular.io にアクセスして、詳細な情報やガイダンスを確認してください。最高のアップデート体験を得るためには、まず Angular 8 の最終リリースにアップデートすることをお勧めします。

First, update to the latest version of 8

まず、Angular 8 の最新バージョンにアップデートします。

Then, update to 9

それから、Angular 9 にアップデートします。

To review the key changes with this update, including deprecated APIs, see Updating to Angular version 9 in the Angular documentation.

廃止された API を含む、今回のアップデートの主な変更点を確認するには、Angular ドキュメントの Updating to Angular version 9 を参照してください。

Ivy

Version 9 moves all applications to use the Ivy compiler and runtime by default. In addition to hundreds of bug fixes, the Ivy compiler and runtime offers numerous advantages:

Angular 9 では、すべてのアプリケーションにデフォルトで Ivy コンパイラーとランタイムを使うように変更しました。数百にも及ぶバグ修が行なわれ、Ivy コンパイラーとランタイムは数多くの利点を提供するようになりました。

・Smaller bundle sizes
・Faster testing
・Better debugging
・Improved CSS class and style binding
・Improved type checking
・Improved build errors
・Improved build times, enabling AOT on by default
・Improved Internationalization

• より小さなバンドルサイズ
• より高速なテスト
• より良いデバッグ
• 改善された CSS の class と style のバインディング
• 改善された 型チェック
• 改善されたビルドエラー
• デフォルトで AOT が有効となり、改善されたビルド時間
• 改善された多言語化

Here’s a breakdown of some of the more notable improvements.

以下は、より注目すべき改善点の内訳です。

Smaller bundle sizes – より小さなバンドルサイズ

The Ivy compiler has been designed to remove parts of Angular that aren’t being used via tree-shaking and to generate less code for each Angular component.

Ivy コンパイラーは tree-shaking で使用されていない Angular の一部を取り除き、各 Angular コンポーネントの生成するコードをより小さくするためにデザインされました。

With these improvements, small apps and large apps can see the most dramatic size savings.

これらの改善によって、小規模なアプリと大規模なアプリは劇的にサイズを小さくすることができるでしょう。

・Small apps that don’t use many Angular features can benefit most from tree-shaking.
・Large apps with many components can benefit most from the reduced factory size.
・Medium-sized apps should see bundle sizes that are on par or slightly smaller, since they benefit less from tree-shaking and don’t have enough components to truly leverage smaller factories.

• それほど多くの Angular の機能を使っていない小規模なアプリは、tree-shaking の恩恵を最も受けるでしょう。
• 多くのコンポーネントを持つ大規模なアプリは 小さくなった factory のサイズにより最も恩恵を受けるでしょう。
• 中規模なアプリは、tree-shaking の恩恵が少なく、小さな factory を真に活用するのに十分なコンポーネントがないため、バンドルサイズは同等またはわずかに小さくなるだけです。

Faster testing – より高速なテスト

We have also revamped the implementation of TestBed in Ivy to make it more efficient.

我々はまた Ivy における TestBed の実装をより効率的となるように刷新しました。

Previously, TestBed would recompile all components between the running of each test, regardless of whether there were any changes made to components (for example, through overrides).

以前は、TestBed は、（たとえばオーバーライドなど）コンポーネントに対しての変更があるかないかに関わらず、各テストの実行ごとにすべてのコンポーネントを再コンパイルしていました。

In Ivy, TestBed doesn’t recompile components between tests unless a component has been manually overridden, which allows it to avoid recompilation between the grand majority of tests.

Ivyでは、TestBed はコンポーネントが手動でオーバーライドされていない限りテスト間で再コンパイルしなくなりました。これにより、大部分のテスト間の再コンパイルを回避できるようになっています。

With this change, the framework’s core acceptance tests are about 40% faster. We would expect users to see their own application test speeds to be around 40–50% faster.

この変更により、フレームワークの core の受け入れテストは、約 40% 速くなりました。おそらく多くのユーザーのアプリケーションテストは約 40-50% 速くなると見ています。

Better debugging – より良いデバッグ

Ivy provides you with more tools to debug your applications. When running an application in Dev Mode with the Ivy runtime, we now offer the new ng object for debugging.

Ivy はアプリケーションをデバッグするために多くのツールを提供します。開発モードで Ivy のランタイムを使ってアプリケーションを走らせているとき、新しいデバッグのための ng オブジェクトが使えるようになりました。

・You can ask Angular for access to instances of your components, directives, and more
・You can manually call methods and update state
・When you want to see the results of change detection, you can trigger change detection with applyChanges

• コンポーネント、ディレクティブなどのインスタンスへのアクセスを Angular にリクエストできます。
• メソッドや state の更新を手動で行えます。
• 変更検知の結果を見たいときに、applyChanges を使って変更検知へのトリガーすることができます。

Ivy also improves the stack trace for debugging issues such as the ExpressionChangedAfterItHasBeenCheckedError. Previously the stack trace could be unhelpful:

さらに、Ivy はExpressionChangedAfterItHasBeenCheckedError のような問題をデバッグするためのスタックトレースを改善しました。以前のスタックトレースは不親切なものでした。

With Ivy, you see a more useful stack trace that allows you to jump directly to the template instruction with the expression that has changed.

Ivy を使うと、変更された式を含むテンプレートの命令に直接ジャンプできる、より便利なスタックトレースが表示されます。

For example, if you click on AppComponent_Template in the stack trace above, you can see the specific line in the generated code where the error is being thrown:

たとえば、もし上記のスタックトレースの中の AppComponent_Template をクリックした場合、エラーが投げられている生成されたコードの特定の行を確認することができます。

If you’re so inclined, you can also step into any of these framework instructions to walk through how the framework creates or updates your components.

その気であれば、これらのフレームワークの命令の中に入り込んで、フレームワークがコンポーネントを作成または更新する方法を確認することもできます。

Improved CSS class and style binding – 改善された CSS の class と style のバインディング

The Ivy compiler and runtime provides improvements for handling styles. Previously, if an application contained competing definitions for a style, those styles would destructively replace each other. With Ivy, the styles are merged in a predictable way.

Ivy のコンパイラーとランタイムはスタイルのハンドリングを改善しています。以前は、アプリケーションに競合するスタイルの定義が含まれていた場合、それらのスタイルは破壊的にお互いを置き換えていました。 Ivy を使用すると、スタイルは予測可能な方法でマージされます。

Consider the following template and component snippets:

以下のようなテンプレートやコンポーネントのスニペットをご検討ください。

@Component({
  host: {
    style: "color:blue"
  },...
})
...

@Directive({
  host: {
    style: "color:black",
    "[style.color]": "property"
  },...
})
...

Previously, whichever binding was evaluated last would win, and this could depend on the timing of changes to these expressions. If myColor and myOtherColor both were undefined, the static ‘red’ style would be ignored.

以前は、バインドされるものは最後に評価されるものが優先され、これらの式の変更のタイミングに依存していました。 myColor と myOtherColor の両方が undefined だった場合、静的な「red」のスタイルは無視されました。

With version 9, you can manage your styles through a clear, consistent order of precedence that isn’t dependent on timing. The most specific styles always have the highest precedence. For example, a binding to [style.color] overrides a conflicting binding to [style].

Angular 9 では、タイミングに依存しない明確で一貫した優先順位でスタイルを管理できます。最も詳細なスタイルは常に最高の優先度となります。たとえば、[style.color] へのバインドは、競合する [style] へのバインドをオーバーライドします。

However, for backwards compatibility reasons, we have left [ngStyle] and [ngClass] bindings behavior the same as before. When their binding values are updated, the new values will override any competing bindings.

しかし、後方互換性の理由から、[ngStyle] と [ngClass] のバインディングの動作は以前と同じままにしています。これらがバインドしている値が更新されたとき、新しい値は競合するバインディングをオーバーライドします。

You can read more about styling precedence rules in the Template Syntax guide in the documentation.

スタイルの優先度のルールに関するより詳細な内容は、ドキュメントの中の Template Syntax guide でご確認ください。

As a side effect of the styling refactoring, you can now also bind to CSS custom properties (also known as CSS variables).

スタイリングのリファクタリングの副作用として、CSS カスタムプロパティ（CSS変数としても知られている）にもバインドできるようになりました。

<div [style.--main-border-color]=" '#CCC' ">
  <p style="border: 1px solid var(--main-border-color)">hi</p>
</div>

Improved type checking – 改善された 型チェック

The Angular compiler can check more of the types of your application, and it can apply more strict rules. These features will help you and your team catch bugs earlier in the development process.

Angular コンパイラーは、より多くのアプリケーションの型をチェックできるようになり、より厳格なルールを適用できるようになりました。これらの機能は、開発プロセスの早い段階で、あなたやあなたのチームがバグを発見するのに役立つことでしょう。

We support two main flags for additional type checks in addition to the default.:

我々は、デフォルトのものに加え、追加の型チェックのために2つのメインフラグをサポートしました。

・fullTemplateTypeCheck — Activating this flag tells the compiler to check everything within your template (ngIf, ngFor, ng-template, etc)
・strictTemplates — Activating this flag will apply the strictest Type System rules for type checking.

• fullTemplateTypeCheck – このフラグを有効にすると、テンプレート内のすべて（ngIf、ngFor、ng-template など）をチェックするようにコンパイラーに指示します。
• strictTemplates – このフラグを有効にすると、テンプレートの型チェックに最も厳格な型システムのルールを適用します。

To learn more about template type checking options, see the Template type checking guide in the documentation.

テンプレートの型チェックオプションの詳細については、ドキュメントの Template type checking guide を参照してください。

Improved build errors – 改善されたビルドエラー

The new Ivy compiler is not only faster and offers stronger type safety, it also makes all of the error messages easier to read.

新しい Ivy コンパイラーは、高速で型安全性が高いだけでなく、すべてのエラーメッセージを読みやすくします。

In version 8 or View Engine, a typical compiler error would look like the following:

Angular 8 や View エンジンでは、典型的なコンパイラーエラーは以下のようなものでした。

In version 9 with Ivy, the same error looks like:

Ivy を使った Angular 9 では、同じエラーでも以下のようになります。

Improved build times, enabling Ahead-of-Time compiler on by default – デフォルトで AOT コンパイラーが有効となり、改善されたビルド時間

Thanks to Ivy’s new architecture, we’ve made significant improvements to the compiler’s performance.

Ivy の新しいアーキテクチャのおかげで、我々はコンパイラーのパフォマンスに重要な改善をもたらしました。

We measure our compiler’s performance in terms of the overhead on top of a plain TypeScript compilation of an application. For our documentation app (angular.io), this overhead decreased from 0.8x to 0.5x with Ivy, an improvement of nearly 40%.

アプリケーションのプレーンな TypeScript のコンパイルにかかるオーバーヘッドの観点から、コンパイラーのパフォーマンスを測定しました。我々のドキュメントアプリ（angular.io）の場合、Ivy を使うと、このオーバーヘッドは 0.8 倍から 0.5 倍に減少し、40％ 近く改善されました。

These improvements mean that AOT builds can be noticeably faster. Thanks to this speedup, for the first time ever we’re using AOT even for dev-mode builds. This means that `ng serve` now benefits from the same compile-time checking as production builds, significantly improving the developer experience for Angular.

この改善は AOT ビルドは著しく高速となりうるということを意味しています。この高速化のおかげで、開発モードのビルドにも初めて AOT を使用することにしました。このことは、ng serve はプロダクションビルドと同じ compile-time チェックから恩恵を受けることになり、結果として Angular の開発者エクスペリエンスを大幅に改善するということを意味します。

Thanks to the changes in the compiler and runtime, we also no longer require entryComponents. These components will be discovered and compiled automatically by their usage.

コンパイラーやランタイムにおける変更のおかげで、entryComponents は、もはや必要なものではなくなりました。これらのコンポーネントは、使用方法により自動的に検出され、コンパイルされるようになりました。

Improved internationalization (i18n) – 改善された多言語化（i18n）

Internationalization has been a core feature of Angular, where you could build your application once per locale and receive highly optimized and localized applications. In 9.0, we’re making this faster by moving the build-time i18n substitutions later in the build process. This change allowed us to make it up to 10 times faster.

多言語化は Angular のコアな機能となりました。ロケールごとにアプリケーションを 1 度構築し、高度に最適化およびローカライズされたアプリケーションを受け取ることができるでしょう。Angular 9 では、ビルド時の i18n の置換をビルドプロセスの後半にうつすことによって、これを高速化しています。この変更により、最大 10 倍高速化できました。

Read more about the new i18n: @angular/localize and the new angular.json configuration.

新しい i18n（@angular/localize と angular.json の新しい設定方法）についてはこちらでご確認ください。

Other improvements with version 9 – その他の改善点

The team has also been hard at work continuing to improve the full experience of using Angular.

チームは、Angular を使用するすべての体験を改善するために努力を重ねてきました。

More reliable ng update – より信頼性が高くなった ng update

We’ve made some changes to how ng update works to make it more reliable and informative.

我々は、より信頼性と有益性を高めるために、ng update にいくつかの変更を加えました。

・Always use the latest CLI. Starting with 8.3.19 of the CLI, we now use the CLI from the update TARGET version during updates. This means that, going forward, updates will always be handled by the latest CLI automatically.
・Clearer progress updates. ng update now does more to tell you what is going on under the hood. For each migration, you’ll see information about the migration.
・Easier update debugging. By default, ng update runs all of the migrations and leaves the aggregate changes on disk for you to inspect. The version 9 update also introduces the new –create-commits flag. When you run ng update –create-commits, the tool commits the state of your codebase after each migration, so you can step through and understand or debug the changes we are making to your code.

• 常に最新の CLI を使用します。 CLI の 8.3.19 から、アップデートの際は、アップデートする TARGET のバージョンの CLI を使用するようになりました。これは、今後、アップデートは常に最新の CLI によって自動的にハンドリングされるということを意味しています。
• アップデートの進行状況がより明確になります。 ng update は、内部で何が進行しているかを伝えるためにさらに多くのことを行うようになりました。それぞれのマイグレーションごとに、そのマイグレーションに関する情報を確認できるようになるでしょう。
• アップデートのデバッグが簡単になります。 デフォルトでは、ng update はマイグレーションのすべてを実行し、ディスク上に集約された変更を検証用に残します。Angular 9 のアップデートでは、新たに --create-commits フラグも導入されています。ng update --create-commits を実行すると、ツールは各マイグレーションの後にコードベースの状態をコミットします。それ故、ステップ実行してコードに加えた変更を理解またはデバッグすることができるようになっています。

New options for 'providedIn' – providedIn の新しいオプション

When you create an @Injectable service in Angular, you must choose where it should be added to the injector. In addition to the previous `root` and module options, you have two additional options.

Angular で @Injectable でサービスを作るとき、そのサービスがどのインジェクターに追加されるべきか選択しなければいけません。これまでの root やモジュールのオプションに加えて、新たに 2 つのオプションを追加しました。

・platform— Specifying providedIn: ‘platform’ makes the service available in a special singleton platform injector that is shared by all applications on the page.
・any— Provides a unique instance in every module (including lazy modules) that injects the token.

• platform – providedIn: 'platform' と指定すると、サービスはページ上のすべてのアプリケーションによってシェアされる特別なシングルトンのプラットフォームインジェクターで利用可能となります。
• any – トークンをインジェクトするすべてのモジュール（lazy モジュールを含む）に、ユニークなインスタンスを提供します。

Learn more about providedIn in our API documentation.

API のドキュメントで providedIn についての詳細を確認できます。

Component harnesses – コンポーネントハーネス（補助機能）

Testing components has historically relied on using implementation details such as CSS selectors to find components and to trigger events. This meant that whenever a component library changed its implementation, all of the tests relying on those components would need to be updated.

コンポーネントのテストは、これまでコンポーネントやイベントのトリガーを見つけるために CSS セレクターのような実装の詳細を使用することに依存してきました。これは、コンポーネントのライブラリの実装が変更されるたびに、それらのコンポーネントに依存するすべてのテストを更新する必要があったことを意味しています。

In version 9, we are introducing component harnesses, which offer an alternative way to test components. By abstracting away the implementation details, you can make sure your unit tests are correctly scoped and less brittle.

Angular 9 では、コンポーネントテストを代替する方法を提供する component harnesses を導入しました。実装の詳細を抽象化することによって、ユニットテストが適切にスコープ化されること、ユニットテストの脆弱性が少なくなることに確信を持つことができるでしょう。

Most of Angular Material’s components can now be tested via harnesses, and we are making harnesses available to any component author as part of the Component Dev Kit (CDK).

Angular Material のコンポーネントのほとんどはハーネスを介してテストできるようになっています。また、Component Dev Kit（CDK）の一部として、すべてのコンポーネントの作成者がハーネスを利用できるようになっています。

Here’s an example test before harnesses:

以下は、ハーネスを利用していないテスト例です。

it("should switch to bug report template", async () => {
  expect(fixture.debugElement.query("bug-report-form")).toBeNull();
  const selectTrigger = fixture.debugElement.query(
    By.css(".mat-select-trigger")
  );
  selectTrigger.triggerEventHandler("click", {});
  fixture.detectChanges();
  await fixture.whenStable();
  const options = document.querySelectorAll(".mat-select-panel mat-option");
  options[1].click(); // Click the second option, "Bug".
  fixture.detectChanges();
  await fixture.whenStable();
  expect(fixture.debugElement.query("bug-report-form")).not.toBeNull();
});

And the same test with harnesses:

以下は、上記のテストにハーネスを使用した例です。

it("should switch to bug report template", async () => {
  expect(fixture.debugElement.query("bug-report-form")).toBeNull();
  const select = await loader.getHarness(MatSelect);
  await select.clickOptions({ text: "Bug" });
  expect(fixture.debugElement.query("bug-report-form")).not.toBeNull();
});

Learn more about Material’s component harnesses or building your own with the CDK.

Angular Material のコンポーネントハーネスやCDKを使った独自ハーネスの構築方法についてはこちらをご参照ください。

New components – 新しいコンポーネント

You can now include capabilities from YouTube and Google Maps in your applications.

YouTube や Google Maps の機能をアプリケーションに含めることができるようになりました。

・You can render a YouTube Player inline within your application with the new youtube-player. After you load the YouTube IFrame player API, this component will take advantage of it.・We are also introducing google-maps components. These components make it easy to render Google Maps, display markers, and wire up interactivity in a way that works like a normal Angular component, saving you from needing to learn the full Google Maps API.

• 新たに追加された youtube-player コンポーネントを使用することで、アプリケーション内に YouTube プレーヤーをインラインでレンダリングできます。YouTube IFrame プレーヤー API をロードした後に、このコンポーネントが機能するようになります。
• さらに、google-maps コンポーネントも導入しました。このコンポーネントを使用すると、Google Maps のレンダリング、マーカーの表示、および通常の Angular コンポーネントと同様の方法でインタラクティブな機能との接続が容易となり、Google Maps API のすべてを学ぶ必要がなくなります。

IDE & language service improvements – IDE & language service を改善

Significant improvements have been made to the Angular language service extension on the Visual Studio Marketplace. Along with major architectural overhaul to address performance and stability issues, many long-standing bugs have also been fixed. Besides that, some new features include:

Visual Studio のマーケットプライスにある Angular language service 機能拡張を大きく改善しました。パフォーマンスと安定性の問題に対処するための主要なアーキテクチャの見直しとともに、長年存在した多くのバグも修正しました。それに加えて、新機能も追加しています。

・TextMate grammar for Angular Template Syntax, which now enables syntax highlighting in both inline and external templates
・“Go to definition” for templateUrl and styleUrls
・NgModule and type information in hover tooltip

• Angular Template 構文が TextMate 文法に対応し、インラインテンプレートでも外部テンプレートでも構文のハイライト表示が可能になりました。
• templateUrl や styleUrls から “Go to definition” ができるようになりました。
• ホバーされるツールチップに NgModule と 型の情報が表示されるようになりました。

TypeScript 3.7 support – TypeScript 3.7をサポート

Angular has been updated to work with TypeScript 3.6 and 3.7, including the extremely popular optional chaining feature in TypeScript 3.7. To stay in sync with the ecosystem, we’ve also updated our version of other ecosystem dependencies such as Zone.JS and RxJS.

Angular は、TypeScript 3.6 および 3.7 で動作するようにアップデートしました。これには、TypeScript 3.7 で一般的となった optional chaining の機能が含まれます。エコシステムとの同期を保つために、Zone.JS や RxJS など他のエコシステムの依存関係のバージョンも同じくアップデートしました。

Thank you to the community – コミュニティへの感謝

This release is the culmination of over 2 years of work. We’re really excited about the future and possibilities that this work opens up. This wouldn’t be possible without the work of hundreds of people in the community.

今回のリリースは、2年以上の作業の集大成です。我々は、この作品が開く未来と可能性に大変興奮しています。数百を超えるコミュニティの方々の協力なしでは成し遂げることは不可能でした。

v9 Contributors:

以下は、Angular 9 のコントリビューターの方々です。

Aaron Frost, Adam J. Penn, Adam Plumer, Adam Vigneaux, Adrien Crivelli, Ajit Singh, Alain Chautard, Alan Agius, Alexander Ivanov, Alexander von Weiss, Alex Eagle, Alex Rickabaugh, alexzuza, Ali Mirlou, Alison Gale, Alyssa Nicoll, Amadou Sall, AMarinov, Amit Dubey, Anders Kjær Damgaard, Andrew Kushnir, Andrew Scott, Andrew Seguin, Andrius, Andrus Diaz, Ankit Prajapati, Aravind, Aristeidis Bampakos, Arne Hoek, Artur Androsovych, arturovt, Atef Ben Ali, Ayaz Hafiz, Ben Elliott, Benjamin Liii, Brian Michalski, CaerusKaru, Carlos Ortiz García, Cédric Exbrayat, Charles Lyding, Christian Liebel, Christopher Dahm, codingnuclei, Colum Ferry, Craig Spence, cran-cg, crisbeto, Cyrille Tuzi, Daniele Morosinotto, Daniel Waxweiler, Danny Skoog, David Sánchez, David Shevitz, Denis Omelkov, Denys Vuika, Diego Juliao, dishanfernando, Dmitri Ischenko, Dominik Pieper, Do Nhu Vy, Doug Parker, Dyma, EddyP23, Edy Segura, Eliran Eliassy, Elvis Begovic, Emmanuel DEMEY, Ephraim, Erik Pintar, Esteban Gehring, Eusen, Evan Martin, FabianGosebrink, FaustmannChr, FDIM, Ferdinand Malcher, FG-33, Filipe Silva, Gabor Szekely, Gabriel Medeiros Coelho, GavinMK, Geoff Bass, George Kalpakas, Gérôme Grignon, ghiscoding, Girma Nigusse, Greg Magolan, Grigoriy Beziuk, hafiz, Harinder Singh, Hayouung, Hoel IRIS, horn, idzark, Igor Minar, Issei Horie, ivanwonder, Jakub Pawlot, James Vickery, Jan Malchert, Jason Bedard, Jeff Held, Jennifer Fell, Jeremy Elbourn, JiaLiPassion, Jithil P Ponnan, jnavb, Joakim Zebic, Joey Perrott, john li, John Ralph Umandal, Jonathan Sharpe, Joost Koehoorn, Jordan Amman, Jordan Nelson, Joshua Colvin, Judy Bogart, J Z, Kai Röder, Kapunahele Wong, Kara Erickson, katryo, Kayla Altepeter, Keen Yee Liau, ketangote, Kirk Larkin, Koala, Kristina Gocheva, kristinavavrova, Kristiyan Kostadinov, Kwinten Pisman, Kyle J. Kemp, Lars Gyrup Brink Nielsen, LASLEDJ, lazarljubenovic, Leonardo Zizzamia, Leon Radley, Luka Petrovic, Mansour Fall, manzonif, Mark Goho, Martina Kraus, Martin Probst, Matias Niemelä, Matthew Harris, Matt Janssen, Mayur Barge, mbehrlich, mertdeg2, Michael Maier, Michael Nahkies, Michael Prentice, Michał Koziara, Mike Brocchi, Mike Casebolt, mikef, Miles Malerba, Minko Gechev, Mirco Widmer, Misko Hevery, Miško Hevery, Mitchell Skaggs, mohax, Muhammad Umair, Muhammad Umair Khan, Nathan Tate, Németh Tamás, Nicolas Villanueva, Nikita Potapenko, Niklas Merz, noeri, Noopur, NothingEverHappens, ODAVING, Olegas Goncarovas, Olivier Combe, Orlando Pozo, owenmecham, Pascal Fivian, paulceli, Paul Gschwendtner, Pawel Kozlowski, Pete Bacon Darwin, Phaneendra, philonor, Pierre-Yves FARE, Piotr Błażejewicz, Potapy4, Rado Kirov, Ralf D. Müller, Raz Luvaton, Reuben Wilson, Richard Lea, Rick Katka, Robert Coie, Robin Dupret, Roy, Rudar Daman Singla, Rustam, Sachin, Sahan Serasinghe, Sam Julien, Santosh Yadav, Sasha Rudan, Sergey Koshechkin, Sergey Nikitin, Shibasish, Sholka Jadav, Showtim3, ShubhrankR, Simon Jespersen, Simon Kurtz, skrikl, Smartin, Sonu Kapoor, Srichandradeep Choudarapu, Sriram Jayarman, Stefanie Fluin, Stephen Cooper, Stephen Fluin, Suguru Inatomi, Suresh918, Syu Kato, thanhpd, thekiba, TheMushr00m, Tiep Phan, Timar, Tim Deschryver, TinyMan, Tom Kwong, Tom Sullivan, Trevor Karjanis, Troels Lenda, Turtuvshin Byambaa, Vanessa Schmitt, Victor, Vikash Dahiya, Vikram Subramanian, Wagner Maciel, Wataru Kasahara, Wenqi, why520crazy, willbeaufoy, William Lohan, WreckItRalph, Yann Bertrand, Younes Jaaidi, Yulia Tsareva, Zaid Al-Omari, zuckjet, 陈旭.

We would also like to thank our GDEs and the community at large. The feedback, issue reports, and reproductions we receive are essential to holding our work to the highest quality standards. There are already over 4000 public Angular apps using version 9.

さらに、GDE（google developer expert）のみなさんとコミュニティ全体に感謝します。我々が受け取るフィードバック、issueの報告、リプロダクションは、最高の品質基準を維持するために不可欠なものです。Angular 9を使用する Angular 製のアプリはすでに 4,000 を超えているからです。

Special thanks to our long term enterprise collaborator Pawel Kozlowski and his sponsor Amadeus. Pawel made a huge quantity of contributions with exceptional quality over the 2 years of the Ivy project that have been a critical part of the project’s success.

長期にわたる企業コラボレーターの Pawel Kozlowski と彼のスポンサーの Amadeus に感謝します。 Pawel は、プロジェクトの成功における重要な部分を担った 2年以上にも及ぶ Ivy プロジェクトで、並外れた品質で多大な貢献をしてくれました。

If you have feedback on this release, please file an issue, or let us know!

このリリースについて何かフィードバックがありましたら、issue を記録しておいてください、もしくはお知らせください！

訳者まとめ

以上、Angular公式ブログの記事『Version 9 of Angular Now Available — Project Ivy has arrived!』の翻訳でした。原文も載せていますので、わかりにくい部分があれば、そちらも合わせてお読みください。