Previously, the correct behavior of Angular custom elements relied on
the constructor being called (and thus the `injector` property being
initialized). However, some polyfills (e.g. `document-register-element`)
do not call the constructor of custom elements, which resulted in the
`injector` property being undefined and the `NgElementStrategy` failing
to be instantiated.
This commit fixes it by being tolerant to the `injector` property being
undefined and falling back to the injector passed to the
`createCustomElement()` config.
NOTE:
We don't have proper tests exercising the situation where the
constructor is not called. For now this is tested using a Google
internal test suite (which is how this issue was caught).
This commit also adds a rudimentary unit test to emulate this situation.
PR Close#36114
Previously, if an element started out as a regular `HTMLElement` (not a
Custom Element) and was later upgraded to a Custom Element, any
properties corresponding to component inputs that were set on the
element before upgrading it would not be captured correctly and thus not
reflected on the instantiated component.
This commit fixes it by ensuring that such properties are captured
correctly.
Jira issue: [FW-2006](https://angular-team.atlassian.net/browse/FW-2006)
Fixes#30848Closes#31416
PR Close#36114
Previously, the `TestStrategy` `NgElementStrategy` used in
`createCustomElement()` tests was created once and re-used in each test
(due to complications related to how `customElements.register()` works).
As a result, the `TestStrategy` instance's state (e.g. inputs) could be
polluted from previous tests and affect subsequent ones.
This commit ensures the strategy instance is reset before each test.
PR Close#36114
Previously, helper modules/components classes were declared even if the
tests were not run (because the environment did not support Custom
Elements for example).
This commit moves the declaration of the helpers inside the `describe()`
block, so they are not declared unnecessarily. This is in preparation of
adding more helpers that need to access variables declared inside the
`describe()` block.
PR Close#36114
Previously, we had to check whether `NgElementStrategy` had been
instantiated before accessing it. This was tedious and error prone,
since it was easy to forget to add the check in new call sites.
This commit switches to using a getter, so that the check has to be
performed in one place and is transparent to call sites (including any
future ones).
PR Close#36114
`createCustomElements()` creates some getters/setters for properties
corresponding to component inputs that delegate to the
`NgElementStrategy`. However, it is not guaranteed that the element's
`NgElementStrategy` will have been created when these getters/setters
are called, because some polyfills (e.g. `document-register-element`) do
not call the constructor.
Previously, trying to get/set input properties before connecting the
element to the DOM (via `connectedCallback()`) would fail due to
`NgElementStrategy` not being created.
This commit ensures that the `NgElementStrategy` is always created
before used inside the input property getters/setters (similar to how it
is done for other methods of `NgElement`).
Mentioned in https://github.com/angular/angular/pull/31416/files#r300326698.
PR Close#36114
The info about the pw storage is out of date.
We should really just point the reader to a go link, something like go/angular/passwords and keep
the info about secrets there.
PR Close#37212
The TOC at the top refers to an anchor that does not exist.
This change adds the missing anchor while preserving the old one in case someone depends on it.
PR Close#37212
`ts-node` is now an optional peer dependency of the shared dev-infra
package. Whenever a `ng-dev` command runs, and a TypeScript-based
configuration file exists, `ts-node` is set up if available.
That allows consumers of the package (as the components repo) to more
conveniently use a TypeScript-based configuration for dev-infra.
Currently, commands would need to be proxied through `ts-node`
which rather complicates the setup:
```
NG_DEV_COMMAND="ts-node ./node_modules/@angular/dev-infra-private/cli.js"
```
I'm thinking that it should be best-practice to use TypeScript for
writing the configuration files. Given that the tool is used primarily
in Angular projects (for which most sources are TypeScript), this should
be acceptable.
PR Close#37196
Adds a deprecation notice to the old merge-pr script informing the
user the script will be removed in favor of the ng-dev merge tooling.
This currently serves as a warning, and does not fail to perform the
merge.
PR Close#37204
PR #36601 itroduces icons on all links if the link contains https:// or http:// but there were some internal links left which contained https://angular.io. Removed https://angular.io from all these links.
PR Close#37157
The `rev` property has been in the initial commit that introduced
`resources.json` (196203f6d76ac5240d1485dbd9701bfb026eab56) and has been
added to all new entries since (always with the value `true`). This
field is a remnant from back when this data was stored in a Firebase
Database and the `rev` field indicated whether the entry has been
reviewed/approved by a DevRel lead or something. Now that the data is
kept in the repository and the reviewing is done as part of the
corresponding PR, this field is no longer necessary.
PR Close#37181
Creates a tool in ng-dev which rebases a PR automatically and pushes
the rebase commits back to the PR. This is meant to be a replacement
to the local merge script currently in the repo and currently has
feature parity.
PR Close#37055
PR #13380 added support for `null` and `undefined` but the type on the parameter was not updated.
This would result in a compilation error if `fullTemplateTypeCheck` is enabled.
Fixes#36544
PR Close#37018
As mentioned in the previous commit, the autosquash strategy has
not been used in the components repo, so we could easily regress.
After thorough manual testing of the autosquash strategy again,
now that the merge script will be moved to framework, it came
to mind that there is a bug with the base revision in the
autosquash merge strategy. The problem is that the base revision
of a given PR is relying on the amount of commits in a PR.
This is prone to error because the amount of commits could easily
change in the autosquash merge strategy, because fixup or squash
commits will be collapsed. Basically invalidating the base revision.
To fix this, we fixate the base revision by determining the actual
SHA. This one is guaranteed to not change after the autosquash rebase.
The current merge script in framework fixates the revision by creating
a separate branch, but there is no benefit in that, compared to just
using an explicit SHA that doesn't need to be cleaned up..
PR Close#37184
The components repo does not use the autosquash merge strategy, so
recent changes to that seem to broke the autosquash strategy.
Since we don't run the rebase in interactive mode, the `--autosquash`
flag has no effect. This is by design in Git. We can make it work by
setting the git sequence editor to `true` so that the rebase seems
like an interactive one to Git, while it isn't one for the user.
This matches conceptually with the merge script currently used in
framework. The only difference is that we allow a real interactive
rebase if the `commit message fixup` label is applied. This allows
commit message modifications (and others) if needed.
PR Close#37184
Integrates the merge script into the `ng-dev` CLI. The goal is that
caretakers can run the same command across repositories to merge a pull
request. The command is as followed: `yarn ng-dev pr merge <number>`.
PR Close#37184
Moves the merge script from the components repository over
to the shared dev-infra package. The merge script has been
orginally built for all Angular repositories, but we just
kept it in the components repo temporarily to test it.
Since everything went well on the components side, we now
move the script over and integrate it into the dev-infra package.
PR Close#37184
This commit includes a couple minor fixes for the script that compares master and patch branch:
- take only relevant release commit into account while generating the diff
- fix the initial version display (avoid '+' sign from being added)
- removes obsolete parameter that was needed for v9.0.x branch only
PR Close#37150
This commit includes the following improvements:
- Document that the `create-image.sh` script (and by extention the
`update-preview-server.sh` script) need to have access to a `yarn`
executable.
- Add a note on cron jobs running in non-interactive, non-login shells
(which affects their execution context and have different behavior vs
running the same commands in an interactive, login shell).
- Change the Node.js and `yarn` installation instructions to ensure the
`yarn` executable will be available on the `PATH` and not require an
interactive, login shell (as happens, for example, when installing it
via [nvm](https://github.com/nvm-sh/nvm)). This makes it easier to set
up a cron job that runs the `update-preview-server.sh` script.
NOTE: The equivalent updates have been made on the GCE VM that hosts the
PR preview server.
PR Close#37015
In order to avoid unnecessary operations, the `update-preview-server.sh`
script, that is used to update the PR preview server Docker container,
will only try to update the Docker container if either any files in the
`aio/aio-builds-setup/` directory have changed since the last update or
if a previous update failed. A failed previous update is detected by
checking whether the temporary `aio-builds:provisional` Docker image
still exists. This temporary image is created during the update
operation and is renamed to `aio-builds:latest` if the update goes well.
Previously, the update script was not able to detect a previous failed
attempt if the operation failed before creating the
`aio-builds:provisional` Docker image, such as if the `create-image.sh`
script failed. This could lead to a situation where the preview server
Docker container would not be updated after a failed attempt.
This commit improves the logic for detecting failed attempts to account
for this type of failures. It does this by not removing an older
`aio-builds:provisional` Docker image until a new one is successfully
created.
NOTE: While this is not full-proof, it is an improvement as it
eliminates a certain kind of failures.
PR Close#37015
Previously, the CHANGELOG file was caught under the general
"*" glob, which meant that it fell under the dev-infra
approval group. This does not really make sense since it
has more to do with public-facing changes. As such, this
commit moves the CHANGELOG file specifically to the
public-api approval group.
PR Close#37143
The _tViewNode field (that was marked as internal) on the ViewRef is not
necessery as a reference to a relevant TView is available as a local
variable.
PR Close#36814
Creates a tool in ng-dev to determine the PRs which become conflicted
by merging a specified PR. Often the question is brought up of how
many PRs require a rebase as a result of a change. This script allows
to determine this impact.
PR Close#37051
Note: This commit was applied to the 9.1.x branch
out of order because local changes were not pushed
directly after the 9.1.7 release. You can see what
is actually included in 9.1.7 using its tag here:
https://github.com/angular/angular/commits/9.1.7
PR Close#37116
`skipLibCheck` had to be added to a few AIO examples, because of a breaking change in master. These changes update to a newer version of `angular-in-memory-web-api` that accounts for the breaking change.
PR Close#37128
Previously this inline-tag-def was returning the `doc` which is rendered
to the output as `[Object Object]` - obviously not what is intended.
Now it returns `''` which effectively strips the tag handler from the
rendered output.
PR Close#37132
Adds the gitub configuration to the ng-dev configuration. This github
configuration provides information needed for making API requests to
github. Upcoming tooling related PRs will require these API requests
being possible.
PR Close#37097
Adds a gitub object to the common configuration for ng-dev. This github
configuration provides information needed for making API requests to
github.
PR Close#37097
After rewriting much of the router doc, it became apparent that the lazy loading/preloading information should be in the lazy loading doc rather than in the router doc. There is now instead a short section that touches on lazy loading but links to the lazy learning document instead of covering it in detail in the router doc.
PR Close#36748
