Since, 7186f9c01 `compiler-cli` is no longer depending on `shelljs` for
production code. (We still use it in tests and infrastructure/tooling.)
Incidentally, this should also help with #29460.
PR Close#31468
Previously, the `test-pwa-score` script would only check the `pwa`
score. (All categories were reported, but a min. score could only be
specified for `pwa`.)
This commit adds support for checking the scores on all available
categories (such as a11y, performance, seo, etc.).
PR Close#31414
This commit slightly improves the log outout of the `test-pwa-score`
script (e.g. by showing the total duration, indenting messages to group
them together, etc.). It, also, includes various minor refactorings.
These changes are in preparation of augmenting the script to support
checking the scores on all available categories (such as a11y,
performance, seo, etc.) in a subsequent commit.
PR Close#31414
This is slightly faster (15%-20%). Currently, this doesn't make a
noticeable difference, since the total time is 10s-15s, but it might
add up, if we decide to run audits on multiple pages.
PR Close#31414
Removes direct calls from one instruction into another, moves the shared logic into a separate function and removes the state getters from the shared function.
This PR resolves FW-1340.
PR Close#31456
The `ScrollService` sets up some global `window` listeners.
Previously, these listeners were never unregistered. This was not a
problem in the real app, because the `ScrollService` instance exists for
the lifetime of a user session. In tests, however, where the `window`
instance is among all tests, the listeners would survive the
`ScrollService` tests. This, in addition to the fact that we used a mock
`ViewportScroller` which did not return the expected type from
`getScrollPosition()`, caused errors to be thrown in unrelated tests
(i.e. whenever a scroll event was emitted on `window`). See [here][1]
for an example failure.
This commit fixes it by adding an `ngOnDestroy()` method that
unregisters the listeners and ensuring it is called after each
`ScrollService` test.
[1]: https://circleci.com/gh/angular/angular/381649
PR Close#31390
Previously, the `search-results` layout was switch from horizontal to
vertical at 480px. Yes, since some search queries can yield more than 5
`.search-area`s, even 600px are too narrow to accomodate a horizontal
layout.
This commit changes the breakpoint at which the layout switches to
vertical from 480px to 600px.
PR Close#31390
Previously, `.search-area` had a default style of `display: flex`, but
it was overriden to `display: block` in media queries for
`max-width: 480px` and `min-width: 600px`. As a result, it only had
`display: flex` between 481px and 599px.
Since no flex layout features are necessary inside `.search-area`, this
commit changes the style to always be `display: block` (i.e. the default
for `div` elements).
PR Close#31390
Previously, resource paths beginning with '/' (aka "rooted" paths, which
are not actually absolute filesystem paths, but are relative to the
TypeScript project root directory) were not handled correctly. The leading
'/' was stripped and the path was resolved as if it was relative, but with
no containing file for context. This led to resources in different rootDirs
not being found.
Instead, such rooted paths are now resolved without TypeScript's help, by
checking each root directory. A test is added to this effect.
PR Close#31511
When determining if a `main` path points to a UMD or CommonJS
format, the contents of the file need to be loaded and parsed.
Previously, it was assumed that the path referred to the exact filename,
but did not account for normal module resolution semantics, where the
path may be missing an extension or refer to a directory containing an
`index.js` file.
// FW-1444
PR Close#31509
Since `goog.getMsg` does not process ICUs (post-processing is required via goog.i18n.MessageFormat, https://google.github.io/closure-library/api/goog.i18n.MessageFormat.html) and placeholder format used for ICUs and regular messages inside `goog.getMsg` are different, the current implementation (that assumed the same placeholder format) needs to be updated. This commit updates placeholder format used inside ICUs from `{$placeholder}` to `{PLACEHOLDER}` to better align with Closure. ICU placeholders (that were left as is prior to this commit) are now replaced with actual values in post-processing step (inside `i18nPostprocess`).
PR Close#31459
Prior to this commit, the `` unicode symbol that represents `&ngsp` in translations was not handled correctly, i.e. was not replaced with a whitespace, thus appearing on a screen. This commit adds post-processing and replaces the mentioned symbol with a whitespace.
PR Close#31479
This commit adds a test that verifies no translations are generated for bound attributes and also checks (as a part of the `verify` function) that VE and Ivy handle this case the same way.
PR Close#31481
`i18nStart` was calling `allocExpando` even if there was 0 new variable created.
This created a new expando instruction with the value 0 which was later interpreted as the start of a new expando block instead of just skipping 0 instructions.
FW-1417 #resolve
PR Close#31451
Fixes Ivy's return value for `DebugNode.context` not being consistent for the case where there is both a structural directive and a component on a node. In `ViewEngine` the instance of the component would be returned, whereas in Ivy the context of the directive is returned.
Also adds a couple of extra test cases for how `DebugNode.context` deals with directives.
This PR resolves FW-1343.
PR Close#31442
Adds a new `elementContainer` instruction that can be used to avoid two instruction (`elementContainerStart` and `elementContainerEnd`) for `ng-container` that has text-only content. This is particularly useful when we have `ng-container` inside i18n sections.
This PR resolves FW-1105.
PR Close#31444
Paths can be mapped directly to files, which was not being taken
into account when computing `basePaths` for the `EntryPointFinder`s.
Now if a `pathMapping` pattern does not exist or is a file, then we try
the containing folder instead.
Fixes#31424
PR Close#30525
Previously, ngcc had to walk the entire `node_modules` tree looking for
entry-points, even if it only needed to process a single target entry-point
and its dependencies.
This added up to a few seconds to each execution of ngcc, which is noticeable
when being run via the CLI integration.
Now, if an entry-point target is provided, only that target and its entry-points
are considered rather than the whole folder tree.
PR Close#30525
When profiling ngcc it is notable that a large amount of time
is spent dealing with an exception that is thrown (and handled
internally by fs) when checking the existence of a file.
We check file existence a lot in both finding entry-points
and when TS is compiling code. This commit adds a simple
cached `FileSystem`, which wraps a real `FileSystem` delegate.
This will reduce the number of calls through to `fs.exists()` and
`fs.readFile()` on the delegate.
Initial benchmarks indicate that the cache is miss to hit ratio
for `exists()` is about 2:1, which means that we save about 1/3
of the calls to `fs.existsSync()`.
Note that this implements a "non-expiring" cache, so it is not suitable
for a long lived `FileSystem`, where files may be modified externally.
The cache will be updated if a file is changed or moved via
calls to `FileSystem` methods but it will not be aware of changes
to the files system from outside the `FileSystem` service.
For ngcc we must create a new `FileSystem` service
for each run of `mainNgcc` and ensure that all file operations
(including TS compilation) use the `FileSystem` service.
This ensures that it is very unlikely that a file will change
externally during `mainNgcc` processing.
PR Close#30525
This message gets called if a format has already been
compiled and we only want the first. So the message itself
is wrong but it is also not very useful anyway.
PR Close#30525
The ngcc tool adds namespaced imports to files when compiling. The ngtsc
tooling was not processing types correctly when they were imported via
such namespaces. For example:
```
export declare class SomeModule {
static withOptions(...): ModuleWithProviders<ɵngcc1.BaseModule>;
```
In this case the `BaseModule` was being incorrectly attributed to coming
from the current module rather than the imported module, represented by
`ɵngcc1`.
Fixes#31342
PR Close#31367
If a package delcares a class internally on an NgModule, ngcc
needs to be able to add a public export to this class's type.
Previously, if the typing file for the declared is not imported
from the typings entry-point file, then ngcc cannot find it.
Now we try to guess the .d.ts files from the equivalent .js
files.
PR Close#31411
This partially reverts some changes from 71b9371180 (diff-dd469785fca8680a5b33b1e81c5cfd91R1420)
These broke the g3sync of zone.js because we use the output of the TypeScript compiler directly, rather than rely on the rollup commonjs plugin to define the global symbol
PR Close#31453
George Kalpakas
Pawel Kozlowski
crisbeto
Hamid
Kapunahele Wong
Stefanie Fluin
Tzvi Melamed
Rudolf Olah
Matias Niemelä
Snehal Baghel
Alex Rickabaugh
Pete Bacon Darwin
Andrew Kushnir
Jason Aden
Filipe Silva
Olivier Combe
Joey Perrott
Alex Eagle