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
The new v5 version of this toolkit is too incompatible for us to run
AIO against both versions. So for now we will ignore this libary when
running against local Angular distributions and continue to use the
version on npm.
PR Close#19511
Upgrading to dgeni-packages 0.21.4 gives us
access to more properties on the API docs, which
allows us to fix the following issues:
Closes#19450Closes#19452Closes#19456
`ng build ...` must be the last command on the corresponding yarn script,
because it needs to be passed extra arguments (such as the target environment)
in specific cases.
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
For classes, the tree of subclasses is rendered, recursively.
For interfaces, the descendants are separated into child interfaces, which
extend the interface, and classes, which implement the interface.
Closes#19306
There are now 3 modes for deployment: next, stable, archive.
We compute which mode (and other deployment properties)
from the `TRAVIS_BRANCH` and the `STABLE_BRANCH`.
If the TRAVIS_BRANCH is master we deploy as "next".
If the `TRAVIS_BRANCH` matches the `STABLE_BRANCH` we deploy as "stable".
Otherwise if the branch has a major version lower than the stable version
and its minor version is highest of similar branches we deploy as "archive".
For "archive" deployments we compute the firebase project and deployment
url based on the major version of the `TRAVIS_BRANCH`.
As well as choosing where to deploy the build, we also use this
to select the environment file for the AIO Angular app.
This will enable the app to change its rendering and behaviour
based on its mode.
See #18287Closes#18297
There are now 3 modes for deployment: next, stable, archive.
We compute which mode (and other deployment properties)
from the `TRAVIS_BRANCH` and the `STABLE_BRANCH`.
If the TRAVIS_BRANCH is master we deploy as "next".
Otherwise if the branch is the highest of its minor versions
we deploy as "stable" if the `TRAVIS_BRANCH` matches the `STABLE_BRANCH` or
else "archive".
For "archive" deployments we compute the firebase project and deployment
url based on the major version of the `TRAVIS_BRANCH`.
As well as choosing where to deploy the build, we also use this
to select the environment file for the AIO Angular app.
This will enable the app to change its rendering and behaviour
based on its mode.
See #18287
This version fixes the DISCONNECTED errors (described in #17543) and removes the
need to the workaround (8af203c).
The relevant jasmine commit is jasmine/jasmine@c60d66994.
You can now specify what environment you are building
by add it to the `yarn build` command. For example:
```
yarn build -- --env=stage
```
Moreover the `deploy-to-firebase.sh` script will automatically apply the
appropriate environment.
The current stable branch is determined based on the current version mapped to
the npm `latest` tag (by replacing the patch version number with 'x' - e.g.
`1.2.3` --> `1.2.x`).
PRs against the stable branch will be deployed to the preview server (as long as
the rest of the requirements are met). Commits on the stable branch itself will
be deployed to production.
Fixes#16908
Rather than hard coding excludes into the dgeni config,
use the fact that we are already ignoring the boilerplate
and generated files via the .gitignore file.
This contains a fix for the typescript module reader.
Previously, TS modules that were of the form:
```
a/b/index.ts
```
Would be given the name `index` and id of `a/b/index`.
This is not desirable, so the new version of dgeni-packages/typescript
removes this `index` from the id and name, which results in name of
`b` and id of `a/b`.
Parse all `<img>` tags, during doc-gen, and insert the width and height of
the sourceed image, if neither are already specified.
Warnings are reported if the `<img>` tag has no `src` attribute or the image
cannot be loaded.
The work is done in the `addImageDimensions` post-processor, which must be
configured with a `basePath` so that it knows where to find the images.
Closes#15888
The autolinking is now done on the `renderedContent` which means it also
captures and autolinks headings that were generated outside of markdown.
PR Close#16336
This task is suitable for day to day docs authoring.
This task cuts corners, which makes it much faster than a full `yarn docs`
run but it does not produce completely valid output.
In general this isgood enough for authors to see their changes as they make them.
The task is triggered by a call to
```
yarn docs-watch
```
This sets up watchers on the `aio/contents` and `packages` folders.
Any changes to files below these folders new doc generation run to start.
The input to the generation is confined to a collection of files related
to the changed file. For example:
* a change to a file in `aio/content/marketing` will generate all the
marketing files.
* a change to a file in `aio/content/tutorial` or `aio/examples/toh-*`
will generate all the tutorial files (and their embedded examples).
* a change to a file in `aio/guide` or `aio/examples` (but not a `toh-`
example) will generate the appropriate guide and its embedded examples
* a change to a file in `packages` or `packages/examples` will generate
the appropriate API doc and its embedded examples.
Be aware that the mapping between docs and its examples are based on doc file
and example folder structure being equivalent. Sometimes a doc will reference
an example in a different folder, in which case the generated doc will be
inaccurate. Mostly this is not a big problem.
The implementation adds three plugins to the remark processor:
* remove support for code blocks triggered by indented
text - only gfm triple backticks are supported; and also adds support for
dgeni inline tags.
* ignore content within `code-example` and `code-tabs` elements. This prevents
the content being accidentally treated as markdown
* ignore dgeni inline tags, e.g. `{@link ... }` to prevent the content of
the links from being accidentally treated as markdown
The markdown renderer passes its output through an HTML pretty printer.
While this is good in most cases, it makes a mess of elements that expect
their content to be left untouched.
The pretty printer already ignores `pre` tags (and other built-ins) by
default. This fix allows us to specify other tags that should be left
alone.
Further it actually specifies this option for `code-example` and `code-pane`
tags, which expect to contain preformatted content.