Skip to main content

Browse the archive

https://github.com/angular/angular
19 April 2024, 08:24:33 UTC
sort by:
Revision Author Date Message Commit Date
9d747e3 Alex Rickabaugh 21 July 2021, 21:53:53 UTC release: cut the v12.2.0-next.3 release (#42916) PR Close #42916 21 July 2021, 21:55:49 UTC
23d6133 Alex Rickabaugh 21 July 2021, 21:52:09 UTC docs: release notes for the v12.1.3 release 21 July 2021, 21:52:09 UTC
e2aa765 George Kalpakas 20 July 2021, 09:36:26 UTC fix(docs-infra): fix keyword color in CLI pages code blocks (#42889) Previously, names of CLI commands that also happened to be keywords were shown in black color in the code block demonstrating the command's usage. This worked fine when in light mode (where the code block background is white) but not in the recently introduced dark mode (where the code block background is dark gray). This commit fixes this by ensuring the `.kwd` token color is inherited from its parent (which has an appropriate color for the current theme). Previously, the `.kwd` token was reset to its initial value (which is `black` regardless of the theme). **Before:** ![CLI pages keyword before][1] **After:** ![cli-pages-keyword after][2] [1]: https://user-images.githubusercontent.com/8604205/126073803-af317f0c-d04f-4c3a-9a83-e92541d7dd5a.png [2]: https://user-images.githubusercontent.com/8604205/126073806-1d57e3ed-90b1-4735-ae2a-d0a39862bb95.png PR Close #42889 20 July 2021, 18:56:33 UTC
70c3461 JoostK 17 July 2021, 20:50:03 UTC fix(compiler-cli): use correct module import for types behind a `forwardRef` (#42887) The static interpreter assumed that a foreign function expression would have to be imported from the absolute module specifier that was used for the foreign function itself. This assumption does not hold for the `forwardRef` foreign function resolver, as that extracts the resolved expression from the function's argument, which is not behind the absolute module import of the `forwardRef` function. The prior behavior has worked for the typical usage of `forwardRef`, when it is contained within the same source file as where the static evaluation started. In that case, the resulting reference would incorrectly have an absolute module guess of `@angular/core`, but the local identifier emit strategy was capable of emitting the reference without generating an import using the absolute module guess. In the scenario where the static interpreter would first have to follow a reference to a different source that contained the `forwardRef` would the compilation fail. In that case, there is no local identifier available such that the absolute module emitter would try to locate the imported symbol from `@angular/core`. which fails as the symbol is not exported from there. This commit fixes the issue by checking whether a foreign expression occurs in the same source file as the call expression. If it does, then the absolute module specifier that was used to resolve the call expression is ignored. Fixes #42865 PR Close #42887 20 July 2021, 18:56:05 UTC
ca7d4c3 dario-piotrowicz 15 July 2021, 20:59:57 UTC refactor(docs-infra): migrate aio from tslint to eslint (#42820) migrate aio to eslint as tslint has been deprecated, the migration is restricted to the aio app and its e2e tests and does not include the other tools, for such reason both tslint and codelyzer have not been removed (to be done in a next PR) some minor tweaks needed to be applied to the code so that it would adhere to the new ESLinting behaviour most TSLint rules have been substituted with their ESLint equivalent, with some exceptions: * [whitespace] does not have an ESLint equivalent (suggested to be handled by prettier) * [import-spacing] does not have an ESLint equivalent (suggested to be handled by prettier) * [ban] replaced with [no-restricted-syntax] as there is no (official/included) ESLint equivalent some rules have minor different behaviours compared to their TSLint counterparts: * @typescript-eslint/naming-convention: - typescript-eslint does not enforce uppercase for const only. * @typescript-eslint/no-unused-expressions: - The TSLint optional config "allow-new" is the default ESLint behavior and will no longer be ignored. * arrow-body-style: - ESLint will throw an error if the function body is multiline yet has a one-line return on it. * eqeqeq: - Option "smart" allows for comparing two literal values, evaluating the value of typeof and null comparisons. * no-console: - Custom console methods, if they exist, will no longer be allowed. * no-invalid-this: - Functions in methods will no longer be ignored. * no-underscore-dangle: - Leading and trailing underscores (_) on identifiers will now be ignored. * prefer-arrow/prefer-arrow-functions: - ESLint does not support allowing standalone function declarations. - ESLint does not support allowing named functions defined with the function keyword. * space-before-function-paren: - Option "constructor" is not supported by ESLint. - Option "method" is not supported by ESLint. additional notes: * the current typescript version used by the aio app is 4.3.5, which is not supported by typescript-eslint (the supported versions are >=3.3.1 and <4.3.0). this causes a warning message to appear during linting, this issue should likely/hopefully disappear in the future as typescript-eslint catches up * The new "no-console" rule is not completely equivalent to what we had prior the migration, this is because TSLint's "no-console" rule let you specify the methods you did not want to allow, whilst ESLint's "no-console" lets you specify the methods that you do want to allow, so and in order not to have a very long list of methods in the ESLint rule it's been decided for the time being to simply only allow the "log", "warn" and "error" methods * 4 dependencies have been added as they have been considered necessary (see: https://github.com/angular/angular/pull/42820#discussion_r669978232) extra: * the migration has been performed by following: https://github.com/angular-eslint/angular-eslint#migrating-an-angular-cli-project-from-codelyzer-and-tslin * more on typescript-eslint at: https://github.com/typescript-eslint/typescript-eslint PR Close #42820 20 July 2021, 18:55:28 UTC
282e86a Joey Perrott 16 July 2021, 00:06:15 UTC fix(dev-infra): use the version from package.json rather than tags (#42872) Use the version value from the primary package.json file rather than checking the branch for the latest semver tag. This allows for us to explictly create changelogs from the previous version to the new version. PR Close #42872 20 July 2021, 18:30:33 UTC
445fee4 Joey Perrott 20 July 2021, 00:04:38 UTC feat(dev-infra): update package version verification to allow for experimental version (#42898) The angular-cli repo publishes experimental versioned packages in addition to standard versioned packages. Both experimental and standard verions, based on the expected new version provided are treated as valid and correct. PR Close #42898 20 July 2021, 18:30:00 UTC
52dc65d dario-piotrowicz 18 July 2021, 09:32:26 UTC build(docs-infra): improve @usageNotes message (#42888) improve the @usageNotes message by adding the word "is" (outcome: "Further information is available in...", compared to "Further information available in...") PR Close #42888 20 July 2021, 00:37:56 UTC
307dac6 JoostK 17 July 2021, 19:26:12 UTC fix(core): use correct injector when resolving DI tokens from within a directive provider factory (#42886) When a directive provides a DI token using a factory function and interacting with a standalone injector from within that factory, the standalone injector should not have access to either the directive injector nor the NgModule injector; only the standalone injector should be used. This commit ensures that a standalone injector never reaches into the directive-level injection context while resolving DI tokens. Fixes #42651 PR Close #42886 20 July 2021, 00:36:29 UTC
722eb5d George Kalpakas 17 July 2021, 16:30:02 UTC fix(docs-infra): prevent main content from overlapping with ToC (#42884) Previously, if there was more content than what would horizontally fit in the main content area, it would overflow to the right and overlap with the Table of Contents (ToC). This was accidentally introduced in #42787. This commit fixes it by ensuring that the main content area will not overlap with ToC and the necessary space for the ToC will be reserved using `margin` (instead of `padding`, which contributes to the element's size). Fixes #42867 PR Close #42884 20 July 2021, 00:35:35 UTC
e7c7707 George Kalpakas 17 July 2021, 11:41:45 UTC fix(docs-infra): correctly handle reported errors (#42883) Error-handling in AIO happens mainly in two places: 1. For errors happening inside the app we have a custom `ErrorHandler` implementation, `ReportingErrorHandler`. `ReportingErrorHandler` passes errors to the default `ErrorHandler` (for them to be logged to the console) and also forwards them to `window.onerror()`. 2. Errors happening outside the app and errors forwarded by `ReportingErrorHandler` are handled by `window.onerror()`, which in turn reports them to Google analytics. Previously, we were making some assumptions (which turned out to be incorrect based on the info captured in Google analytics - see #28106): - `ReportingErrorHandler` assumed that the errors passed to its `handleError()` method would be either strings or `Error` instances. _Apparently, other values (such as `null` or `undefined`) may also be passed._ - `window.onerror()` assumed that if an `Error` instance was passed in, it would always have a stacktrace (i.e. its `stack` property would be defined). _This is not necessarily true, although it is not clear (based on the logs) whether reported errors of this type are caused by `Error` instance with no stacktrace or by non-string error objects which are incorrectly treated as `Error` instances. This commit ensures that all types of error arguments can be handled correctly, including `Error` instances with no stacktrace and other types of objects or primitives. NOTE: PR #42881 is related as it fixes handling `null` and `undefined` arguments in the default `ErrorHandler`. Fixes #28106 PR Close #42883 20 July 2021, 00:35:02 UTC
7eddd12 Paul Gschwendtner 16 July 2021, 18:18:18 UTC feat(dev-infra): add option to setup global types in API golden test (#42876) Previously we disabled automatic type-resolution for the API extractor because in non-sandbox environments this resulted in different API reports. There are cases where global types are still needed for analysis of an entry-point. To support this, we add a new property called `types` which allows for explicit type targets being specified. Note that we do not want to determine types from the `data` runfiles because API extractor itself also brings in types which should not always be part of the API report analysis. PR Close #42876 20 July 2021, 00:33:19 UTC
7271ad1 Paul Gschwendtner 16 July 2021, 17:23:09 UTC ci: remove RBE workaround from `components-repo-unit-tests` job (#42875) In the past when we had issues with our RBE instance, we wanted to get CI green as soon as possible, and couldn't wait on the components repo to land their RBE instance fix. We manually fixed the RBE instance name using a CI step using `sed`. This is no longer needed if we update to the most recent state of the components repository. PR Close #42875 20 July 2021, 00:32:44 UTC
30165f9 Paul Gschwendtner 15 July 2021, 19:23:13 UTC build: remove unnecessary husky gitignore file (#42870) We recently updated to Husky v7 through Renovate, but as of Husky v7, a `.gitignore` file is no longer needed. This commit removes the file. PR Close #42870 20 July 2021, 00:31:55 UTC
4286b08 Paul Gschwendtner 15 July 2021, 18:39:24 UTC ci: exempt bazel scope from merge tool target label checks (#42869) Currently, changes with the `bazel` scope are guarded by the merge tool target label checks. i.e. feature commits with the `bazel` scope cannot land in the patch branch. This is expected for all public packages, but given the `bazel` package being used internal-only, it should be possible to land these in a patch branch. Especially since we want tooling to be in sync between version branches as much as possible. PR Close #42869 20 July 2021, 00:29:01 UTC
96d31d8 Joey Perrott 15 July 2021, 23:35:57 UTC fix(dev-infra): prevent verbose messaging of git checkout and commit for release (#42871) Prevent logging verbose messages to the output for commit and checkout during the release process. PR Close #42871 20 July 2021, 00:15:53 UTC
fd92a3e Joey Perrott 15 July 2021, 23:28:26 UTC fix(dev-infra): perform actual npm login verification for wombot proxy (#42871) Previously the wombot proxy was not able to be queried for login state, now that it is able to be checked via `npm whoami` a specific alternate flow is no longer needed. PR Close #42871 20 July 2021, 00:15:53 UTC
89509df Joey Perrott 15 July 2021, 23:26:26 UTC refactor(dev-infra): provide entire pull request object to waitForPullRequestToBeMerged (#42871) `waitForPullRequestToBeMerged` should get the entire `PullRequest` object rather than just the id to allow it to have more information/context for logging and messaging. PR Close #42871 20 July 2021, 00:15:53 UTC
5327926 Joey Perrott 15 July 2021, 23:22:04 UTC fix(dev-infra): don't pollute standard out during commit message hooks (#42871) When a commit message is not restored, there is not need to log this to stdout. It is a better experience to silently succeed. PR Close #42871 20 July 2021, 00:15:53 UTC
0ce8f6e dario-piotrowicz 17 July 2021, 19:35:35 UTC refactor(animations): remove unused animation trigger imports (#42763) in the animation_trigger.ts file there are unused imports remove them to clean up the file PR Close #42763 20 July 2021, 00:13:45 UTC
b41a2b3 dario-piotrowicz 17 July 2021, 12:37:36 UTC refactor(animations): remove publicApi annotations from triggers (#42763) the buildTrigger function and AnimationTrigger class are annotated as publicApi which seems wrong and makes changes to the two problematic, so they are being removed here see: https://github.com/angular/angular/pull/42763/files#r671481902 PR Close #42763 20 July 2021, 00:13:45 UTC
f12c533 dario-piotrowicz 04 July 2021, 08:57:55 UTC fix(animations): normalize final styles in buildStyles (#42763) the final styles created in buildStyles lack normalization, meaning that pixel values remain as numbers (without "px") and so such properties fail to be correctly set/applied Example: "width: 300" is applies as "width": "300" (and thus ignored) instead of the correct "width": "300px" PR Close #42763 20 July 2021, 00:13:45 UTC
5d7359e dario-piotrowicz 17 July 2021, 09:53:26 UTC refactor(animations): fix typo in transition animations spec file (#42763) fix the typo "mean't" in the transition_animation_engine spec file to "meant" (the typo is simply in a code comment so the change does not have any impact) PR Close #42763 20 July 2021, 00:13:45 UTC
3b2f607 Paul Gschwendtner 18 June 2021, 14:03:29 UTC build: generate closure locale files using hard-coded list of locales (#42230) With the refactoring from a Gulp task to a Bazel too, we tried switching away from the hard-coded list of locales and aliases for the Closure Locale file generation. After multiple attempts of landing this, it turned out that Closure Compiler/Closure Library relies on locale identifiers CLDR does not capture within it's `availableLocales.json` or `aliases.json` data. Closure Library does not use any unknown locale identifiers here. The locale identifiers can be resolved within CLDR using the bundle lookup algorithm that is specified as part of CLDR; instead the problem is that the locale identifiers do not follow any reasonable pattern and therefore it's extremely difficult to generate them automatically (it's almost like we'd need to build up _all_ possible combinations). Instead of doing that, we just use the hard-coded locales and aliases from the old Closure Locale generation script. PR Close #42230 16 July 2021, 19:44:59 UTC
9d1deb1 Paul Gschwendtner 10 June 2021, 18:56:25 UTC build: generate alias locale data for closure locale (#42230) Within Google, closure compiler is used for dealing with translations. We generate a closure-compatible locale file that allows for registration within Angular, so that Closure i18n works well together with Angular applications. Closure compiler does not limit its locales to BCP47-canonical locale identifiers. This commit updates the generation logic so that we also support deprecated (but aliased) locale identifiers, or other aliases which are likely used within Closure. We use CLDR's alias supplemental data for this. It instructs us to alias `iw` to `he` for example. `iw` is still supported in Closure. Note that we do not manually extract all locales supported in Closure; instead we only support the CLDR canonical locales (as done before) + common aliases that CLDR provides data for. We are not aware of other locale aliases within Closure that wouldn't be part of the CLDR aliases. If there would be, then Angular/Closure would fail accordingly. PR Close #42230 16 July 2021, 19:44:59 UTC
e640db1 Paul Gschwendtner 02 June 2021, 13:50:07 UTC build: simplify generation of closure locale file (#42230) In the past, the closure file has been generated so that all individual locale files were imported individually. This resulted in a huge slow-down in g3 due to the large amount of imports. With 90bd984ff74f7605d7c08fd9fdbf610ba7fa67a5 this changed so that we inline the locale data for the g3 closure locale file. Also the file only contained data for locales being supported by Closure. For this a list of locales has been extracted from Closure Compiler, as well as a list of locale aliases. This logic is prone to CLDR version updates, and also broke as part of the Gulp -> Bazel migration where this logic has been slightly modified but caused issues in G3. e.g. a locale `zh-Hant` was requested in g3, but the locale data had the name of the alias locale that provided the data at index zero (which represents the locale name). Note that the locale names at index zero always could differentiate from the requested `goog.LOCALE` due to the aliasing logic. This just didn't come up before. We simplify this logic by generating a `goog.LOCALE` case for all locales CLDR provides data for. We don't need to bother about aliasing because with the refactorings to the CLDR generation tool, all locales are built (which also captures the aliases), and we can generate the locale file on the fly (which has not been done before). PR Close #42230 16 July 2021, 19:44:59 UTC
87b9ceb Paul Gschwendtner 25 May 2021, 19:36:07 UTC build: add documentation for `generate-locales-tool` (#42230) The CLDR extraction tool has been reworked to run as part of Bazel. This adds a initial readme explaining what the tool generates. It's far from a detailed description but it can serve as foundation for more detailed explanations. PR Close #42230 16 July 2021, 19:44:59 UTC
1c5b130 Paul Gschwendtner 22 May 2021, 17:18:31 UTC build: build locale files for legacy saucelabs job (#42230) Given that the locale files are now generated through Bazel, the files are no longer checked-in and the legacy TSC compilation fails due to imports resolving to non-existent files. We fix this for the legacy saucelabs job by copying the generated TS files into the sources (which is acceptable for the isolated CI job) PR Close #42230 16 July 2021, 19:44:59 UTC
444d838 Paul Gschwendtner 21 May 2021, 20:58:25 UTC build: wire up new CLDR generation tool within Bazel (#42230) Introduces a few Starlark macros for running the new Bazel CLDR generation tool. Wires up the new tool so that locales are generated properly. Also updates the existing `closure-locale` file to match the new output generated by the Bazel tool. This commit also re-adds a few locale files that aren't generated by CLDR 37, but have been accidentally left in the repository as the Gulp script never removed old locales from previous CLDR versions. This problem is solved with the Bazel generation of locale files, but for now we re-add these old CLDR 33 locale files to not break developers relying on these (even though the locale data indicies are incorrect; but there might be users accessing the data directly) PR Close #42230 16 July 2021, 19:44:59 UTC
7a3a453 Paul Gschwendtner 21 May 2021, 20:57:42 UTC build: convert CLDR locale extraction from Gulp to Bazel tool (#42230) Converts the CLDR locale extraction script to a Bazel tool. This allows us to generate locale files within Bazel, so that locales don't need to live as sources within the repo. Also it allows us to get rid of the legacy Gulp tooling. The migration of the Gulp script to a Bazel tool involved the following things: 1. Basic conversion of the `extract.js` script to TypeScript. This mostly was about adding explicit types. e.g. adding `locale: string` or `localeData: CldrStatic`. 2. Split-up into separate files. Instead of keeping the large `extract.js` file, the tool has been split into separate files. The logic remains the same, just that code is more readable and maintainable. 3. Introduction of a new `index.ts` file that is the entry-point for the Bazel tool. Previously the Gulp tool just generated all locale files, the default locale and base currency files at once. The new entry-point accepts a mode to be passed as first process argument. based on that argument, either locales are generated into a specified directory, or the default locale, base currencies or closure file is generated. This allows us to generate files with a Bazel genrule where we simply run the tool and specify the outputs. Note: It's necessary to have multiple modes because files live in separate locations. e.g. the default locale in `@angular/core`, but the rest in `@angular/common`. 4. Removal of the `cldr-data-downloader` and custom CLDR resolution logic. Within Bazel we cannot run a downloader using network. We switch this to something more Bazel idiomatic with better caching. For this a new repository rule is introduced that downloads the CLDR JSON repository and extracts it. Within that rule we determine the supported locales so that they can be used to pre-declare outputs (for the locales) within Bazel analysis phase. This allows us to add the generated locale files to a `ts_library` (which we want to have for better testing, and consistent JS transpilation). Note that the removal of `cldr-data-downloader` also requires us to add logic for detecting locales without data. The CLDR data downloader overwrote the `availableLocales.json` file with a file that only lists locales that CLDR provides data for. We use the official `availableLocales` file CLDR provides, but filter out locales for which no data is available. This is needed until we update to CLDR 39 where data is available for all such locales listed in `availableLocales.json`. PR Close #42230 16 July 2021, 19:44:59 UTC
f2cd6de Paul Gschwendtner 21 May 2021, 20:52:45 UTC refactor: remove checked-in locale files (#42230) This is a pre-refactor commit allowing us to move the CLDR locale generation to Bazel where files would no longer be checked-in, except for the `closure-locale` file that is synced into Google3. PR Close #42230 16 July 2021, 19:44:58 UTC
3da7146 George Kalpakas 16 July 2021, 08:21:21 UTC build(docs-infra): upgrade Lighthouse to version 8.1.0 (#42846) This commit upgrades `lighthouse` to the latest version (8.1.0) to take advantage of latest fixes/improvements and ensure the min scores are still met with the latest audit changes. PR Close #42846 16 July 2021, 17:02:21 UTC
642362a Joey Perrott 14 July 2021, 19:43:39 UTC build: add configuration for caretaker handoff (#42859) Add configuration information about groups for caretaker handoff assistant. PR Close #42859 15 July 2021, 20:34:59 UTC
bc1da1f Joey Perrott 14 July 2021, 19:43:28 UTC feat(dev-infra): create caretaker handoff assistant to update github team membership (#42859) Create a handoff assistant, currently only assists in updating github team membership for caretaking team. PR Close #42859 15 July 2021, 20:34:58 UTC
7422821 Renovate Bot 15 July 2021, 08:46:16 UTC build: update dependency @microsoft/api-extractor to v7.18.4 (#42864) PR Close #42864 15 July 2021, 20:34:24 UTC
f5baa55 Minko Gechev 13 July 2021, 23:01:01 UTC docs: remove reference to an obsolete design doc (#42842) The type checking design document is no longer relevant. This PR removes the reference to it. Close #42424. PR Close #42842 15 July 2021, 20:24:58 UTC
4e97514 David Shevitz 13 July 2021, 22:59:06 UTC docs: remove references to future in topic (#42841) Fixes #25704 PR Close #42841 15 July 2021, 20:23:28 UTC
670300e Renovate Bot 14 July 2021, 20:24:55 UTC build: lock file maintenance (#42824) PR Close #42824 15 July 2021, 20:22:37 UTC
ea93672 dario-piotrowicz 03 July 2021, 10:42:39 UTC docs(docs-infra): remove unnecessary "Podcast" from happy-angular podcast's title (#42756) PR Close #42756 15 July 2021, 20:22:03 UTC
c556128 dario-piotrowicz 03 July 2021, 10:41:40 UTC docs(docs-infra): add the angular show to the podcast resources (#42756) PR Close #42756 15 July 2021, 20:22:03 UTC
c11bcb7 dario-piotrowicz 03 July 2021, 10:24:58 UTC docs(docs-infra): podcast keys cleanup in resources.json (#42756) PR Close #42756 15 July 2021, 20:22:03 UTC
ca1fde9 dario-piotrowicz 03 July 2021, 09:28:02 UTC docs(docs-infra): remove deep dive from podcast resources (#42756) PR Close #42756 15 July 2021, 20:22:03 UTC
31593db JoostK 28 June 2021, 21:07:41 UTC refactor(core): expand error logging when the JIT compiler is not available (#42693) If a decorator or partial declaration has not been AOT compiled, then the compiler is needed at runtime to be able to JIT compile the code. However, it may occur that the compiler is not available, if it has not been loaded into the application. The error that was reported in this case did not provide insight into which class requested compilation, nor did it differentiate between decorators vs. partial declarations. This commit expands the error logging to provide better insight into the class that initiated JIT compilation and offers a specialized error message for partial declarations. This should help a developer better understand why the error occurs and what can be done to resolve it. Closes #40609 PR Close #42693 15 July 2021, 20:19:05 UTC
07d7e60 JoostK 15 March 2021, 22:28:28 UTC perf(compiler-cli): optimize cycle detection using a persistent cache (#41271) For the compilation of a component, the compiler verifies that the imports it needs to generate to reference the used directives and pipes would not create an import cycle in the program. This requires visiting the transitive import graphs of all directive/pipe usage in search of the component file. The observation can be made that all directive/pipe usages can leverage the exploration work in search of the component file, thereby allowing sub-graphs of the import graph to be only visited once instead of repeatedly per usage. Additionally, the transitive imports of a file are no longer collected into a set to reduce memory pressure. PR Close #41271 15 July 2021, 20:13:48 UTC
437759b Krzysztof Kotowicz 08 July 2021, 11:36:54 UTC revert: docs: remove references to Trusted Types due to incompatibility with Webpack 5 (#42796) Re-add reference to Trusted Types since the issue #41754 is resolved in 12.1.1. This reverts commit 7254fbc2baa1455e3b24400597342843df3017f2. PR Close #42796 14 July 2021, 18:14:08 UTC
48c1c81 Alan Agius 14 July 2021, 16:20:54 UTC docs: remove End-to-end test files structure (#42844) Since version 12, the Angular CLI no longer generates end-to-end tests. PR Close #42844 14 July 2021, 18:12:42 UTC
64bb7cd David Shevitz 13 July 2021, 22:53:22 UTC docs: update incorrect bullet text (#42839) Fixes #42286 PR Close #42839 14 July 2021, 18:11:56 UTC
0b429d3 Andrew Kushnir 14 July 2021, 17:59:59 UTC release: cut the v12.2.0-next.2 release (#42858) 14 July 2021, 17:59:59 UTC
4b8f7c8 Andrew Kushnir 14 July 2021, 17:55:46 UTC docs: release notes for the v12.1.2 release (#42857) 14 July 2021, 17:55:46 UTC
cd2d82a JoostK 10 July 2021, 21:24:03 UTC fix(core): associate the NgModule scope for an overridden component (#42817) When using `TestBed.overrideComponent`, the overridden component would incorrectly lose access to its NgModule's declaration scope if the NgModule had been imported into the testing NgModule as a `ModuleWithProviders`, e.g. using a `forRoot` call. The issue occurred as the `TestBed` compiler did not consider NgModules that had been imported as a `ModuleWithProviders` when associating NgModules with component overrides. This caused the overridden component to be compiled standalone, meaning that it does not have access to its NgModule's declarations. This commit extends the logic for traversing the NgModule graph to also consider `ModuleWithProviders` imports. Fixes #42734 PR Close #42817 13 July 2021, 22:59:28 UTC
51156f3 JoostK 28 June 2021, 19:35:03 UTC fix(core): allow proper type inference when `ngFor` is used with a `trackBy` function (#42692) In #41995 the type of `TrackByFunction` was changed such that the declaration of a `trackBy` function did not cause the item type to be widened to the `trackBy`'s item type, which may be a supertype of the iterated type. This has introduced situations where the template type checker is now reporting errors for cases where a `trackBy` function is no longer assignable to `TrackByFunction`. This commit fixes the error by also including the item type `T` in addition to the constrained type parameter `U`, allowing TypeScript to infer an appropriate `T`. Fixes #42609 PR Close #42692 13 July 2021, 21:08:05 UTC
970d7f7 David Shevitz 13 July 2021, 17:28:37 UTC docs: update routing-overview topic with link to custom route matches tutorial (#42837) PR Close #42837 13 July 2021, 21:07:15 UTC
e42aa6c Meir Blumenfeld 12 July 2021, 16:44:07 UTC fix(common): re-sort output of `KeyValuePipe` when `compareFn` changes (#42821) Previously, if only the `compareFn` changed but the data itself did not, then the `KeyValuePipe` did not re-sort the output. Fixes #42819 PR Close #42821 13 July 2021, 18:33:21 UTC
81dce5c Daniel Trevino 22 June 2021, 15:48:27 UTC fix(compiler-cli): check split two way binding (#42601) Check for split two way binding when output is not declared to make error message clearer. PR Close #42601 13 July 2021, 15:47:11 UTC
88b15d5 Mark Goho 01 July 2021, 21:05:48 UTC docs: clarify voting phase for feature requests (#42663) PR Close #42663 12 July 2021, 22:25:46 UTC
c1c1cda Andrew Kushnir 12 July 2021, 21:58:53 UTC Revert "refactor(dev-infra): add spawnSync to child process utils, normalize naming of child-process utils (#42394)" (#42829) This reverts commit 08444c6679e88034f021cc4ce8d1a0dd85ac4e46. PR Close #42829 12 July 2021, 22:24:55 UTC
3d66816 Andrew Kushnir 12 July 2021, 21:58:35 UTC Revert "refactor(dev-infra): remove usages and dependency on shelljs (#42394)" (#42829) This reverts commit f0d857eff876033359a7c284171775041f75db5d. PR Close #42829 12 July 2021, 22:24:54 UTC
b33665a Kristiyan Kostadinov 11 July 2021, 08:24:55 UTC fix(compiler): add mappings for all HTML entities (#42818) Angular inserts text either through text nodes (`document.createTextNode`) or using `textContent`, but the drawback of doing so is that HTML entities won't be decoded. In order to work around it, the compiler has some logic that maps the entities to their unicode representation which can safely be inserted. The problem is that our current mapping is arbitrarily limited which means that some entities will be mapped while others will throw an error, even though they're valid. These changes expand the list to cover all entities that are supported by the HTML spec. Fixes #41186. PR Close #42818 12 July 2021, 21:41:20 UTC
f0d857e Joey Perrott 27 May 2021, 19:04:39 UTC refactor(dev-infra): remove usages and dependency on shelljs (#42394) Remove usages of shelljs and instead use spawn/spawnSync. PR Close #42394 12 July 2021, 21:39:08 UTC
08444c6 Joey Perrott 03 June 2021, 17:54:36 UTC refactor(dev-infra): add spawnSync to child process utils, normalize naming of child-process utils (#42394) Create a `spawnSync` command for common usage, additionally update naming to use `spawn` instead of `spawnWithDebugOutput` PR Close #42394 12 July 2021, 21:39:07 UTC
e6593ad Paul Gschwendtner 12 July 2021, 19:02:12 UTC fix(dev-infra): transitive targets cannot be resolved by API extractor (#42828) For API golden tests not running against a NPM package, we extract all transitive declarations of the specified `data` targets. This is necessary because API extractor needs to resolve other targets that have been linked by the Bazel NodeJS rules. The linker by default only provides access to JavaScript sources, but the API extractor is specifically concerned with type definitions that we need to manually extract. PR Close #42828 12 July 2021, 21:38:05 UTC
867000e Paul Gschwendtner 12 July 2021, 18:29:57 UTC fix(dev-infra): do not include all types in api golden test (#42828) The API golden test tool should not include all types from the `node_modules/`. This results in unnecessary type resolution when the API golden tool is run outside of sandbox (i.e. on windows or with `bazel run` for accept). PR Close #42828 12 July 2021, 21:38:05 UTC
9456eca Paul Gschwendtner 10 July 2021, 15:33:54 UTC feat(dev-infra): better caching for browser archive contents (#42814) Adds better caching for browser archives and their extraction. This is done because the archives are currently extracted as a build action and these are actions are invalidated frequently, causing flakiness on the CI and slow-down in local development. Here is an example flaky error on the CI (that surfaces often with RBE execution): ``` ERROR: /home/circleci/.cache/bazel/_bazel_circleci/9ce5c2144ecf75d11717c0aa41e45a8d/external/npm/@angular/dev-infra-private/bazel/browsers/chromium/BUILD.bazel:22:17: Extracting ../org_chromium_chromium_amd64/file/chrome-linux.zip failed: (Exit 34): extract.sh failed: error executing command external/io_bazel_rules_webtesting/web/internal/extract.sh external/org_chromium_chromium_amd64/file/chrome-linux.zip ... (remaining 2 argument(s) skipped). Note: Remote connection/protocol failed with: execution failed ``` We fix this by introducing a new rule that downloads a browser archive and unpacks it directly into a Bazel repository. Before this change, the archive would just be downloaded but extracted later as part of a build action. This is unnecessary and results in less efficient caching as build actions are invalidated more often, especially if developers run `bazel clean` in between. The root cause on why the extraction often fails in RBE containers is unclear. It's unclear why the extacted archive is not cached properly as part of a build action (most likely some hermeticity issue within `rules_webtesting`, but it seems more Bazel-idiomatic to unpack the archives as part of the repository anyway, and this solves the flakiness issue. PR Close #42814 12 July 2021, 21:37:10 UTC
a524af1 Pete Bacon Darwin 04 July 2021, 10:23:30 UTC docs: move start tutorial alert for clarity (#42764) The alert was placed in the middle of a set of steps, which was causing some confusion. This has been moved to the above the steps in the section and slightly reworded to make it clearer. Fixes #42752 PR Close #42764 12 July 2021, 20:20:13 UTC
b5ab7af Paul Gschwendtner 07 July 2021, 17:58:22 UTC refactor: add override keyword to members implementing abstract declarations (#42512) In combination with the TS `noImplicitOverride` compatibility changes, we also want to follow the best-practice of adding `override` to members which are implemented as part of abstract classes. This commit fixes all instances which will be flagged as part of the custom `no-implicit-override-abstract` TSLint rule. PR Close #42512 12 July 2021, 20:11:17 UTC
04642e7 Paul Gschwendtner 06 July 2021, 17:41:48 UTC feat(dev-infra): add lint rule to enforce no-implicit-override abstract members (#42512) TypeScript introduced a new flag called `noImplicitOverride` as part of TypeScript v4.3. This flag introduces a new keyword called `override` that can be applied to members which override declarations from a base class. This helps with code health as TS will report an error if e.g. the base class changes the method name but the override would still have the old method name. Similarly, if the base class removes the method completely, TS would complain that the memeber with `override` no longer overrides any method. A similar concept applies to abstract methods, with the exception that TypeScript's builtin `noImplicitOverride` option does not flag members which are implemented as part of an abstract class. We want to enforce this as a best-practice in the repository as adding `override` to such implemented members will cause TS to complain if an abstract member is removed, but still implemented by derived classes. More details: https://github.com/microsoft/TypeScript/issues/44457. PR Close #42512 12 July 2021, 20:11:16 UTC
1dffa51 Paul Gschwendtner 07 June 2021, 19:06:06 UTC refactor: ensure compatibility with noImplicitOverride for examples (#42512) Adds the `override` keyword to the `examples` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:16 UTC
5b5868d Paul Gschwendtner 07 June 2021, 19:05:50 UTC refactor(zone.js): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `zone.js` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:16 UTC
bfc4c3c Paul Gschwendtner 07 June 2021, 19:05:34 UTC refactor(localize): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `localize` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:16 UTC
368576b Paul Gschwendtner 07 June 2021, 19:05:21 UTC refactor(language-service): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `language-service` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:16 UTC
388496c Paul Gschwendtner 07 June 2021, 19:05:03 UTC refactor(service-worker): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `service-worker` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:16 UTC
01e869a Paul Gschwendtner 07 June 2021, 19:04:52 UTC refactor(forms): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `forms` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:16 UTC
c13ccc3 Paul Gschwendtner 07 June 2021, 19:04:39 UTC refactor(elements): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `elements` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:16 UTC
22290af Paul Gschwendtner 07 June 2021, 19:04:22 UTC refactor(common): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `common` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:16 UTC
ff87da3 Paul Gschwendtner 07 June 2021, 19:04:08 UTC refactor(benchpress): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `benchpress` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:15 UTC
634ba9c Paul Gschwendtner 07 June 2021, 19:03:56 UTC refactor(upgrade): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `upgrade` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:15 UTC
abc77a6 Paul Gschwendtner 07 June 2021, 19:03:42 UTC refactor(router): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `router` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:15 UTC
8948c93 Paul Gschwendtner 07 June 2021, 19:03:01 UTC refactor(platform-server): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `platform-server` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:15 UTC
48c9a0d Paul Gschwendtner 07 June 2021, 19:02:34 UTC refactor(platform-browser-dynamic): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `platform-browser-dynamic` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:15 UTC
a2975c7 Paul Gschwendtner 07 June 2021, 19:02:10 UTC refactor(platform-browser): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `platform-browser` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:15 UTC
c74927d Paul Gschwendtner 07 June 2021, 19:01:40 UTC refactor(core): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `core` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:15 UTC
7313756 Paul Gschwendtner 07 June 2021, 19:00:45 UTC refactor(animations): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `animations` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:15 UTC
9073633 Paul Gschwendtner 07 June 2021, 19:00:18 UTC refactor(dev-infra): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `dev-infra` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:14 UTC
ccbb913 Paul Gschwendtner 07 June 2021, 15:25:45 UTC refactor(compiler-cli): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `compiler-cli` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:14 UTC
96c9326 Paul Gschwendtner 07 June 2021, 15:10:51 UTC refactor(compiler): ensure compatibility with noImplicitOverride (#42512) Adds the `override` keyword to the `compiler` sources to ensure compatibility with `noImplicitOverride`. PR Close #42512 12 July 2021, 20:11:14 UTC
c7d2063 Paul Gschwendtner 07 June 2021, 15:09:00 UTC build: enable noImplicitOverride in project (#42512) Enables the `noImplicitOverride` option to improve overall codehealth in the repository. PR Close #42512 12 July 2021, 20:11:14 UTC
e8be045 Arthur Ming 23 June 2021, 03:39:35 UTC refactor(core): optimize the implementation about finding context from error in ErrorHandler (#42581) in _findContext method, use conditional operator check whether the params 'error' exists and then us reccursion way to find context in original error if getDebugContext's result does not exist. PR Close #42581 12 July 2021, 19:00:19 UTC
1067be7 Arthur Ming 21 June 2021, 01:48:21 UTC build: update all symbol extractor (#42581) update all symbol extractor by running 'yarn symbol-extractor:update' script PR Close #42581 12 July 2021, 19:00:19 UTC
1e2d879 Arthur Ming 16 June 2021, 08:28:56 UTC refactor(core): optimize the implementation about finding context from error in ErrorHandler (#42581) in _findContext method, use conditional operator check whether the params 'error' exists and then use nullish coalescing operator instead conditional operator when getDebugContext's result does not exist. PR Close #42581 12 July 2021, 19:00:19 UTC
404c8d0 Kristiyan Kostadinov 03 July 2021, 09:59:58 UTC fix(compiler): incorrect context object being referenced from listener instructions inside embedded views (#42755) Currently unless a listener inside of an embedded view tries to reference something from the parent view, or if the reference is a local ref, we don't generate the view restoration instructions and we allow for the value to be picked up from the context object in the function parameters. The problem is that the listener is only run during creation mode and the context object may have been swapped out afterwards. These changes fix the issue by always generating the view restoration instructions for listeners inside templates. Fixes #42698. PR Close #42755 12 July 2021, 18:58:18 UTC
4c482bf JoostK 03 July 2021, 22:59:46 UTC fix(compiler-cli): properly emit literal types when recreating type parameters in a different file (#42761) In #42492 the template type checker became capable of replicating a wider range of generic type parameters for use in template type-check files. Any literal types within a type parameter would however emit invalid code, as TypeScript was emitting the literals using the text as extracted from the template type-check file instead of the original source file where the type node was taken from. This commit works around the issue by cloning any literal types and marking them as synthetic, signalling to TypeScript that the literal text has to be extracted from the node itself instead from the source file. This commit also excludes `import()` type nodes from being supported, as their module specifier may potentially need to be rewritten. Fixes #42667 PR Close #42761 12 July 2021, 18:48:34 UTC
40da386 behrooz bozorg chami 10 July 2021, 20:06:22 UTC docs(core): fix `ViewChildren` code examples to avoid TS error (#42816) Add a non-null assertion (`!`) in `ViewChildren` code examples to avoid a TypeScript error due to uninitialized property. Fixes #42811 PR Close #42816 12 July 2021, 16:48:30 UTC
4e73b88 Paul Gschwendtner 09 July 2021, 18:26:19 UTC build: no longer ship ecmascript module files within NPM packages (#42809) We accidentally started shipping `.mjs` files for the following modules (or module paths) as of the v12.1.0-next.2 tag: - `@angular/compiler-cli` - `@angular/common/locales` - `@angular/bazel` - `@angular/benchpress` - `@angular/core/schematics` - `@angular/elements/schematics` - `@angular/language-service` - `@angular/localize/schematics`, - `@angular/localize/tools` - `zone.js` This did not cause any issues for consumers but we want to not ship these files without having them wired up in `package.json` files. We accidentally started shipping these `.mjs` files due to a NodeJS update which wired up the other JavaScript module output flavors in the `pkg_npm` rule. https://github.com/bazelbuild/rules_nodejs/commit/911529fd364eb3ee1b8ecdc568a9fcf38a8b55ca PR Close #42809 12 July 2021, 16:42:01 UTC
9af5abb Paul Gschwendtner 09 July 2021, 18:22:50 UTC feat(dev-infra): add bazel rule for extracting JavaScript module flavors from targets (#42809) Introduces a rule that collects declared JavaScript module output files from a list of dependencies based on a configurable JavaScript module provider. The extracted outputs are exposed within the `DefaultInfo` provider. Targets defined using this rule can be used as input for rules that require JavaScript sources, or if there are multiple JavaScript output variants defined for a target while for example only the `JSModuleInfo` outputs are of interest. As an example: This rule is helpful in combination with `ts_library` and `ng_module` as those rule expose multiple output flavors (which are distinguishable by the JavaScript module providers as imported from `providers.bzl`). i.e. these rules expose flavors for named AMD modules and ECMAScript module output. If we want to ship a NPM package only using ECMAScript modules for example, we could extract all `JSEcmaScriptModuleInfo`-denoted output and feed that into the `pkg_npm` rule, compared to bringing in all output flavors. For reference: https://github.com/bazelbuild/rules_nodejs/blob/stable/packages/typescript/internal/build_defs.bzl#L334-L337 PR Close #42809 12 July 2021, 16:42:01 UTC
ef15b97 dario-piotrowicz 29 June 2021, 21:15:51 UTC docs(core): edit and add docs for ng-template (#42704) PR Close #42704 12 July 2021, 16:39:29 UTC
762e057 Paul Gschwendtner 06 July 2021, 13:45:55 UTC build: update to rules_nodejs v4.0.0-beta.0 (#42760) Updates the Bazel NodeJS rules to v4.0.0-beta.0. This is necessary so that the Angular components repo can update, and it's generally good to stay as up-to-date as possible with the Bazel rules as it's easy to fall behind, and updating early allows us to discover issues affecting our tooling earlier (where they are easier to address due to e.g. potential breaking change policy). PR Close #42760 09 July 2021, 21:50:15 UTC
9da68a7 Paul Gschwendtner 06 July 2021, 13:42:32 UTC refactor(bazel): compatibility with `rules_nodejs` v4.0.0 (#42760) This commit applies changes to `@angular/bazel` which are necessary to support the Bazel NodeJS rules v4.0.0. The Bazel NodeJS rules no longer support the `_tslibrary` option for the `LinkablePackageInfo` provider and therefore we need to stop using it. Due to this removal, we also need to add two new attributes called `package_name` and `package_path` so that the API of `ng_module` matches `ts_library`. Note: This is denoted as `refactor` as we currently are not able to merge feature commits into patch branches, but we want the tooling to not diverge significantly between the patch and next branch. It is planned to update the merge tooling to allow for such changes to land. PR Close #42760 09 July 2021, 21:50:15 UTC
12443ea Paul Gschwendtner 06 July 2021, 13:39:58 UTC build: remove `skydoc` and `rules_sass` from repository (#42760) Skydoc is no longer used as `@angular/bazel` is no longer a public API. The Sass rules were only used in a single place in the repo where Sass is not really needed and has just been added by accident most likely. We want to remove the Sass dependency in preparation for Rules NodeJS v4.x where the Sass rules currently still use an older version of `@bazel/worker` that is incompatible. PR Close #42760 09 July 2021, 21:50:15 UTC
53b281a Paul Gschwendtner 06 July 2021, 13:31:08 UTC build: remove outdated note when updating bazel version (#42760) We removed `bazel-toolchains` from the repository since dev-infra provides the RBE platforms now (in a way where they are not reliant on the Bazel version), so the comment in `.bazelversion` can be removed. PR Close #42760 09 July 2021, 21:50:14 UTC
b1fa1bf Paul Gschwendtner 06 July 2021, 13:29:19 UTC fix(dev-infra): `ng_rollup_bundle` rule should error if import cannot be resolved (#42760) Rollup just prints a warning if an import cannot be resolved and ends up being treated as an external dependency. This in combination with the `silent = True` attribute for `rollup_bundle` means that bundles might end up being extremely small without people noticing that it misses actual imports. To improve this situation, the warning is replaced by an error if an import cannot be resolved. This unveiles an issue with the `ng_rollup_bundle` macro from dev-infra where imports in View Engine were not resolved but ended up being treated as external. This did not prevent benchmarks using this macro from working because the ConcatJS devserver had builtin resolution for workspace manifest paths. Though given the new check for no unresolved imports, this will now cause errors within Rollup, and we need to fix the resolution. We can fix the issue by temporarily enabling workspace linking. This does not have any performance downsides. To enable workspace linking (which we might need more often in the future given the linker taking over patched module resolution), we had to rename the `angular` dependency to a more specific one so that the Angular linker could link into `node_modules/angular`. PR Close #42760 09 July 2021, 21:50:14 UTC
back to top