The StackBlitz API (which we use to generate StackBlitz projects on the
fly, when a user clicks on a live example link in the docs) allows
specifying the file to open in the editor by passing a query param. If
no file is specified, StackBlitz opens a default one.
This commit specifies relevant landing files for some of the examples to
make it easier to engage with the examples more quickly, and to see what
the example is attempting to demonstrate.
Fixes#22357.
PR Close#34553
This reverts commit f029af50820765019413fa319330830306b80d6a while we investigate
some failures on master on Circle CI. Currently the Windows tests and the
"test-ivy-aot" jobs are red because of incompatible yarn versions.
PR Close#34402
Adds the ability to expose global symbols in the API docs via the `@globalApi` tag. Also supports optionally setting a namespace which will be added to the name automatically (e.g. `foo` will be renamed to `ng.foo`). Relevant APIs should also be exported through the `global.ts` file which will show up under `core/global`.
PR Close#34237
Rather than bumping up the allowed version of yarn on each release
we should instead just allow for anything within the major version
1 range.
PR Close#34236
The local Angular packages used to build `aio/` when running
`yarn setup-local`/`yarn build-local` (and related commands), are built
by bazel. Bazel, determines the version to use for these locally built
packages based on the latest tag for a commit on the current branch.
(This works as expected during the release, because the packages are
built on the correct branch with up-to-date tags.)
During local development, however, this often leads to generating older
versions than what the current `@angular/cli` version is compatible
with, if the user has not fetched the latest tags from `angular/angular`
or the branch has not been rebased recently.
Previously, the above (common) situation would result in a build error
by the CLI. (Note that this would be a false error, because in this case
the version set by bazel would not reflect the actual version of the
local packages.) The solution would be for the user to fetch the latest
tags from `angular/angular`, rebase their branch and run a bazel build
again (ensuring that it would actually build anew and not emit cached
artifacts). This was cumbersome and most people didn't even know about
it.
This commit avoids this error and the associated pain-points by
overwriting the versions of the installed local packages with fake
versions based on the ones in the lockfile, which are guaranteed to be
compatible with the currently used CLI version.
Fixes#34208
PR Close#34213
Previously, some RxJS-related examples (which are not proper Angular apps) were not
tested on CI as part of the `example-e2e` npm script. This meant that the examples
could get out-of-date or contain compile errors without as noticing.
This commit ensures that the `example-e2e` script picks up these examples and checks
that they compile successfully.
Partly addresses #28017.
PR Close#34063
Previously any code block, which was not marked with
`no-auto-link` css class would have its contents auto-linked to
API pages. Sometimes this results in false positive links being
generated.
This is problematic for triple backticked blocks, which cannot provide
the `no-auto-link` CSS class to prevent the linking.
This commit fixes the problem by allowing the auto-linker to be
configured not to auto-link code blocks that have been marked with an
"ignored" language. By default these are `bash` and `json`.
Triple backticked blocks are able to specify the language directly after
the first set of triple backticks.
Fixes#33859
PR Close#33877
In #33823, `scripts/package-builds.sh` (which is used by both
`build-packages-dist.sh` and `build-ivy-npm-packages.sh`) was updated to
use `realpath`. It turns out that `realpath` does not exist on macOS, so
the build scripts do not work there.
In order to fix this (and also reduce the likelihood of introducing
similar issues in the future), this commit changes these bash scripts to
Node.js scripts (using [ShellJS](https://github.com/shelljs/shelljs) for
a cross-platform implementation of Unix shell commands where necessary).
PR Close#33854
Currently this repo allows Yarn between 1.17.3 and 1.18.0, whereas the components repo requires a minimum of 1.19.1 which makes it annoying to switch between repositories. These changes bump the maximum allowed Yarn version.
PR Close#33430
Update `protractor` and ensure that the latest version of
`webdriver-manager` (v12.1.7) is installed, which correctly installs a
ChromeDriver version that is compatible with the latest version of
Chrome.
With the previous version of `webdriver-manager`, ChromeDriver v75 would
be installed by default, which was not compatible with the latest
version of Chrome (v77).
PR Close#33206
Previously, when compiling the docs examples with `ngcc` (to run them in
Ivy mode), we would only consider the `es2015` property. However, some
packages (such as `angular-in-memory-web-api`) may not have that
property in their `package.json`. They might still be compilable by
`ngcc`, if they define other format properties (such as `module` or
`main`), but `ngcc` would still fail if it could not find any of the
_specified_ properties (here only `es2015`):
```
Error: Unable to process any formats for the following entry-points (tried es2015):
- /.../node_modules/angular-in-memory-web-api
```
This commit fixes potential issues by considering all properties that
would be considered if `ngcc` was run implicitly by `@angular/cli` and
aligns the command with the one that will be generated for new apps:
https://github.com/angular/angular/blob/3e14c2d02/packages/core/schematics/migrations/postinstall-ngcc/index.ts#L22
PR Close#33206
Update `protractor` and ensure that the latest version of
`webdriver-manager` (v12.1.7) is installed, which correctly installs a
ChromeDriver version that is compatible with the latest version of
Chrome.
With the previous version of `webdriver-manager`, ChromeDriver v75 would
be installed by default, which was not compatible with the latest
version of Chrome (v77).
PR Close#33206
Previously, we would only consider the `es2015` property, but some
packages (such as `angular-in-memory-web-api`) may not have that. They
might still be compilable by `ngcc`, is they have other format
properties (e.g. `module` or `main`).
This commit fixes potential issues by considering all properties that
would be considered via the cli integration and aligns the command to
turn on ivy for docs examples with the one used in new cli apps:
https://github.com/angular/angular/blob/3e14c2d02/packages/core/schematics/migrations/postinstall-ngcc/index.ts#L22
PR Close#33206
Injectable defs are not considered public API, so the property
that contains them should be prefixed with Angular's marker
for "private" ('ɵ') to discourage apps from relying on def
APIs directly.
This commit adds the prefix and shortens the name from
ngInjectableDef to "prov" (for "provider", since injector defs
are known as "inj"). This is because property names cannot
be minified by Uglify without turning on property mangling
(which most apps have turned off) and are thus size-sensitive.
PR Close#33151