Each docs example has an `example-config.json` configuration file. Among
other things, this file can be used to specify what commands to run in
order to test the example. (If not specified, the `run-example-e2e.js`
script will run a default `yarn e2e` command.)
Previously, the property specifying the test commands was called `e2e`.
This is because in the past only e2e tests were run for docs examples.
Since recently, some examples may specify commands for other types of
tests (such as unit tests). Therefore, calling the property that holds
the list of test commands `e2e` no longer makes sense and can be
misleading to people looking at the configuration files.
This commit renamed the property to the more generic `tests`. In the
future, the `run-example-e2e.js` script (and corresponding npm script)
should be renamed and refactored to also avoid giving the impression
that only e2e tests are run.
Discussed in:
https://github.com/angular/angular/pull/36143#discussion_r395148379
PR Close#36143
The `core-js` dependency is no longer included in `package.json` for
`cli`-type examples, but only for the `systemjs` ones. This commit
updates the `package.json` templates to reflect that (and also updates
the `npm-packages` guide accordingly).
PR Close#36143
Previously, only e2e tests were run for docs examples on CI. As a
result, unit tests (which are included in the zipped archives we provide
for users to download and play with the examples locally) were often
outdated and broken.
This commit configures specific docs examples that have meaningful unit
tests to run them on CI (via the `run-example-e2e.js` script). Where
necessary, the unit tests are fixed to ensure they pass and reflect the
changes in the corresponding component/service.
This commit also removes some auto-generated unit tests that are not
meaningful (e.g. make trivial assertions, such that a component instance
is truthy) and are often broken anyway (e.g. because the corresponding
component has been changed in ways that make the tests fail).
PR Close#36143
Previously, the download link to the example for the angular element
guide was in the middle of the page. To make it easier for the user to
find the download link, it has been placed to the top of the page.
This commit partially addresses #35459
PR Close#36067
Since the livestream for ng-conf is not public this year,
(and is only available to ng-conf attendees), we are
removing the link from the angular.io homepage.
Instead, we are now pointing to the ng-conf homepage for
more information.
PR Close#36382
Co-Authored-By: Igor Minar <iminar@google.com>
Updating the recommended defaults for template typechecking strictness to the most strict in order
to catch most of the errors at compile time.
See https://angular.io/guide/template-typecheck for more info.
PR Close#35628
The `removeSystemJsConfig` and `type` properties (present in some
`zipper.json` files) are now obsolete and are not taken into account by
the example zipper:
- `removeSystemJsConfig` is no longer relevant since most examples have
been migrated to use the CLI.
- `type` is no longer relevant, because the project type is determined
based on the `projectType` property in `example-config.json` files.
This commit removes these properties from `zipper.json` files and
updates the `example-zipper` docs to not mention them.
PR Close#36018
The `app-list-item` component sounds like it is used for a single
item, however it renders a list of items. There were also
several changes in the documentation, where it was becoming
confusing if the `app-list-item` is using a single item or multiple
items. This commit fixes this issue. It renames the component and its
respective properties to make sure that the intention is very clear.
Closes#35598
PR Close#35601
1. During reading the documentation I found some code examples that were refering to the class properties via methods, but without specifying the context `this`.
2. The 'onInvoke' hook was duplicated
3. A minor typo on `Zones and execution contexts` section
4. A minor typo on `Zones and async lifecycle hooks` section
PR Close#36138
The AOT compilation section of the `ngUpgrade` guide was
outdated/non-applicable. This commit hides the section to avoid confusion.
Fixing the section and re-introducing it is being tracked in #35989.
PR Close#36015
Previously, the `package.json` files added as boilerplate to docs
example projects of type `systemjs` were incorrect/outdated. They
contained unused dependencies and npm scripts and omitted used
dependencies.
This is not a big issue, because these examples are not offered as live
StackBlitz examples or downloadable ZIP archives, but having incorrect
`package.json` files is confusing and makes it more complicated to
update these examples.
This commit updates the `package.json` templates for the `systemjs` docs
examples and other configuration files to include used dependencies (and
remove unused ones). It also removes unused npm scripts.
PR Close#36015
Update `tsconfig[.*].json`.
Also, all make necessary changes to ensure the example apps can be
successfully built with the new, stricter type-checking options.
PR Close#36015
In the example apps used in the `ngUpgrade` guide, the AngularJS files
are loaded in `index.html` from `https://code.angularjs.org/`. Latest
browsers prevent loading the scripts from a page running on localhost
due to CORS:
```
Access to script at 'https://code.angularjs.org/1.5.5/angular.js' from origin
'http://localhost:9876' has been blocked by CORS policy: No 'Access-Control-Allow-Origin'
header is present on the requested resource.
```
NOTE:
Loading the files from `code.angularjs.org` is not mentioned in the
guide, therefore it is not needed to mention this config change there.
PR Close#36015
The `build` and `run` properties in `example-config.json` are only used
in example projects of type `systemjs`. In CLI-type projects, `build`
and `run` are ignored.
PR Close#36015
The `unittesting` property in `example-config.json` is a remnant of the
setup (before `aio/` was moved into the `angular/angular` repo) and has
no effect any more.
PR Close#36015
This has a couple benefits:
- we now use a .bazelversion file rather than package.json to pin the version of bazel we want. This means even if you install bazel on your computer rather than via yarn, you'll still get a warning if your bazel version is wrong.
- you no longer end up downloading three copies of bazel due to bugs in both npm and yarn where they download all tarballs before checking the metadata to see which are usable on the local platform.
- bazelisk correctly handles the tools/bazel trick for wrapping functionality, which we want to use to instrument developer build latencies
PR Close#36078
Sachin Grover
Alan Agius
Judy Bogart
George Kalpakas
Priyash Patil
Doguhan Uluca
Sonu Kapoor
Ferdinand Malcher
Alexey Okhrimenko
Kara Erickson
John Papa
Faouzi Medebbeb
Aristeidis Bampakos
Abraham Williams
profanis
Andrew Kushnir
Alex Eagle