To avoid unnecessary code duplication in docs examples, we have some
boilerplate files for various example types (in
`aio/tools/examples/shared/boilerplate/`). These files are copied to
each example project in `aio/content/examples/` (according to the
example's type, as specified in its `example-config.json` file).
Previously, the `example-boilerplate.js`, which is responsible for
copying the boilerplate files, had lists for files to be copied for each
project type and only copied the listed files from the boilerplate
directory to the example directory. This approach had some drawbacks:
- Files need to be updated in two separate locations: in the boilerplate
directory that includes the files and the file list in
`example-boilerplate.js`.
- It is easy to add a file in the boilerplate directory but forget to
add it in `example-boilerplate.js` and not realize that it is not
being included in the example project (including the generated
StackBlitz project and ZIP archive).
This commit changes the approach by removing the boilerplate file
listings from `example-boilerplate.js` and copying all files from a
boilerplate directory to example directories. This addresses the above
drawbacks and simplifies the `example-boilerplate.js` script.
I have verified that the resulting code example doc regions as well as
the generated StackBlitz projects and ZIP archives are identical to the
ones generated before this commit.
PR Close#38173
Previously, the `.gitignore` file that is part of the boilerplate files
for CLI-based docs examples (located in
`aio/tools/examples/shared/boilerplate/cli/`) was not added to the
example projects, because it was not included in the boilerplate file
list in `example-boilerplate.js`.
This commit fixes it by adding the `.gitignore` file to the list. This
ensures that docs examples more closely match CLI-generated projects.
PR Close#38173
Docs examples of type `i18n` need a slightly modified version of
`polyfills.ts` that imports `@angular/localize/init`. Previously, this
file was not included in `i18n` example projects for two reasons:
- While the file was included in the `i18n` boilerplate files (at
`aio/tools/examples/shared/boilerplate/i18n/`), it was not included in
the boilerplate file list in `example-boilerplate.js`.
- The file was in the wrong location: It was located at the project root
instead of inside the `src/` directory.
This commit addresses the above issues (i.e. adds the file to the
boilerplate file list for `i18n` projects and moves the file inside the
`src/` directory).
PR Close#38173
Previously, the `elements` docs example only worked in browsers that
natively supported Custom Elements and ES2015 modules. Furthermore, it
didn't work on StackBlitz, because StackBlitz ignores the specified
`target` in `tsconfig.json` and uses the UMD bundles (i.e. ES5 code)
even on browsers that do support ES2015.
(NOTE: In the past, this was not a problem, because we explicitly did
not provide a StackBlitz example. This has changed in #36067.)
This commit ensures the example works on all browsers and also on
StackBlitz by providing the necessary Custom Elements polyfills.
Fixes#36532
PR Close#36536
In #35049, integration and AIO tests were changed to use the browser
provided by `puppeteer` in tests. This commit switches the docs examples
tests to use the same setup.
IMPLEMENTATION NOTE:
The examples are used to create ZIP archives that docs users can
download to experiment with. Since we want the downloaded projects to
resemble an `@angular/cli` generated project, we do not want to affect
the project's Protractor configuration in order to use `puppeteer`.
To achieve this, a second Protractor configuration is created (which is
ignored when creating the ZIP archives) that extends the original one
and passes the approperiate arguments to use the browser provided by
`puppeteer`. This new configuration (`protractor-puppeteer.conf.js`) is
used when running the docs examples tests (on CI or locally during
development).
PR Close#35381
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
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
Previously, the executable for the Angular Compatibility Compiler
(`ngcc`) was called `ivy-ngcc`. This would be confusing for users not
familiar with our internal terminology, especially given that we call it
`ngcc` in all our docs and presentations.
This commit renames the executable to `ngcc` and replaces `ivy-ngcc`
with a script that errors with an informative message (prompting the
user to use `ngcc` instead).
Jira issue: [FW-1624](https://angular-team.atlassian.net/browse/FW-1624)
PR Close#33140
Context:
As part of the `test_docs_examples_ivy` job, we run 5 concurrent builds
on each VM (each for a different example/project). Additionally, all
example projects share the same `node_modules/` (via a symlink to
`aio/tools/examples/shared/node_modules/`), so all concurrent builds
operate on the same files.
Previously, we pre-ran ngcc with `--properties module` to process the
fesm5 bundles. Since we have switched to es2015 in 661a57d9e, we now
need the esm2015 bundles. As a result, the initial ngcc run is
redundant and ngcc runs again during each build (to process the fesm2015
bundles). Since there are 5 concurrent builds, we often end up with
multiple ngcc instances processing the same package and trying to write
to the same directories at the same time, causing a
`file already exists` error
This commit fixes it by pre-processing the esm2015 bundles, so there is
no need to re-run ngcc during each concurrent build.
Fixes#30577
PR Close#30593
Sometimes, in ESM5 code, aliases to exported variables are used internally
to refer to the exported value. This prevented some analysis from being
able to match up a reference to an export to the actual export itself.
For example in the following code:
```
var HttpClientXsrfModule = /** @class */ (function () {
function HttpClientXsrfModule() {
}
HttpClientXsrfModule_1 = HttpClientXsrfModule;
HttpClientXsrfModule.withOptions = function (options) {
if (options === void 0) { options = {}; }
return {
ngModule: HttpClientXsrfModule_1,
providers: [],
};
};
var HttpClientXsrfModule_1;
HttpClientXsrfModule = HttpClientXsrfModule_1 = tslib_1.__decorate([
NgModule({
providers: [],
})
], HttpClientXsrfModule);
return HttpClientXsrfModule;
}());
```
We were not able to tell that the `ngModule: HttpClientXsrfModule_1` property
assignment was actually meant to refer to the `function HttpClientXrsfModule()`
declaration. This caused the `ModuleWithProviders` processing to fail.
This commit ensures that we can compile typings files using the ESM5
format, so we can now update the examples boilerplate tool so that it
does not need to compile the ESM2015 format at all.
PR Close#29092
Now that we are using package.json properties to indicate which
entry-point format to compile, it turns out that we don't really
need to distinguish between flat and non-flat formats, unless we
are compiling `@angular/core`.
PR Close#29092
You can now specify a list of properties in the package.json that
should be considered (in order) to find the path to the format to compile.
The build marker system has been updated to store the markers in
the package.json rather than an additional external file.
Also instead of tracking the underlying bundle format that was compiled,
it now tracks the package.json property.
BREAKING CHANGE:
The `proertiesToConsider` option replaces the previous `formats` option,
which specified the final bundle format, rather than the property in the
package.json.
If you were using this option to compile only specific bundle formats,
you must now modify your usage to pass in the properties in the package.json
that map to the format that you wish to compile.
In the CLI, the `--formats` is no longer available. Instead use the
`--properties` option.
FW-1120
PR Close#29092
Currently when adding the example boilerplate to all
examples with Ivy enabled, we run Ngcc and transform
all found formats. This potentially slows down the build and
is not necessary as we only need the "fesm5" and "fesm2015" bundles.
PR Close#28984
File overwrites:
- **angular.json**: Add `serviceWorker: true` to production config.
- **package.json**: Add `@angular/service-worker` to dependencies.
This will make any `service-worker` examples work out-of-the-box, when
downloading and running locally from the `.zip` archives.
PR Close#28020
Examples using `@angular/elements` need to transpile to es2015 for
Custom Elements to work (on browsers that natively support them).
Alternatively, a polyfill would need to be loaded. For now, changing the
transpilation target to es2015 is the simplest solution.
PR Close#24840
The tooling for boilerplate was also running `yarn install` on the examples'
shared folder. But since this is handled by `ng-packages-installer` this
commit refactors the tools so that the boilerplate no longer does this
anymore.
PR Close#19511
This commit allows building angular.io against the locally built Angular
packages. It adds two new npm scripts:
- `setup-local`: Same as `setup`, but overwrites the Angular packages for both
angular.io and the examples boilerplate with the locally built ones.
- `build-local`: Same as `build`, but uses `setup-local` instead of `setup`
under the hood, thus overwriting installed Angular packages with locally built
ones.
Fixes#18611
With this commit `ngc` is used instead of `tsc-wrapped` for
collecting metadata and tsickle rewriting and `tsc-wrapped`
is removed from the repository.
`@angular/tsc-wrapped@5` is now deprecated and is no longer
used, updated, or maintained as part as of Angular 5.x.x.
`@angular/tsc-wrapped@4` is still maintained and required by
Angular 4.x.x and will be maintained as long as 4.x.x is in
LTS.
PR Close#19298
This commit also updates the version of `@angular/cli` used for docs examples.
The previous (transient) dependency `@ngtools/webpack` was not compatible with
`@angular/compiler-cli@>=5` and was breaking when running against the local
builds (currently at 5.0.0-beta.2). The version of `@ngtools/webpack` used by
the latest `@angular/cli` version is compatible with `@angular/compiler-cli@5`.
George Kalpakas
Yvonne Allen
Matias Niemelä
Brandon
Kapunahele Wong
Jimmy Kasprzak
Pete Bacon Darwin
Judy Bogart
Paul Gschwendtner
Marc Laval
Brandon Roberts
Jesus Rodriguez
Chuck Jazdzewski