The method `ts.CompilerHost.directoryExists` is optional, and was not
previously handled by our ts.CompilerHost wrapper for factory and
summary shims (GeneratedShimsHostWrapper).
TypeScript checks for the existence of this method and silently ignores
things like typeRoots if it's not found. This commit adds proper handling
of directoryExists() to the shim.
A test is also added which verifies typeRoots behavior works when shims
are enabled.
PR Close#27470
PR #27404 introduced additional test case to make sure we generate `elementStyling` instructions with proper set of arguments (first argument was missing in some cases). It looks like that PR was created before we updated host vars count calculation and the `allocHostVars` becomes unnecessary in the test cases introduced in PR #27404. This commit actualizes this test to get rid of unnecessary `allocHostVars` instruction.
PR Close#27473
The logic that generates first argument for the `elementStyling` instruction was missing the check that directive expression is specified. As a result, in some cases first argument was not added, thus making function invocation incorrect. Now the presence of directive expression is taken into account and the `null` expression is generated as needed.
PR Close#27404
Prior to this change `projectDef` instructions were placed to root templates only, thus the necessary information (selectors) in nested templates was missing. This update adds the logic to insert `projectDef` instructions to all templates where <ng-content> is present.
PR Close#27384
Previously ngtsc assumed resource files (templateUrl, styleUrls) would be
physically present in the file system relative to the .ts file which
referenced them. However, ngc previously resolved such references in the
context of ts.CompilerOptions.rootDirs. Material depends on this
functionality in its build.
This commit introduces resolution of resources by leveraging the TypeScript
module resolver, ts.resolveModuleName(). This resolver is used in a way
which will never succeed, but on failure will return a list of locations
checked. This list is then filtered to obtain the correct potential
locations of the resource.
PR Close#27357
This commit adds support for resolution of styleUrls to ngtsc. Previously
this field was never read, and so components with styleUrls would appear
unstyled after compilation.
PR Close#27357
The problem was caused by missing `allocateBindingSlots` that led to incorrect # of vars defined for components and as a result, causing errors at runtime. Now all `bind` operation are accounted for and the number of `vars` is correct.
PR Close#27338
The problem was caused by the self-closing i18n instruction that was generated in case we have styling instructions defined for a component. As a result, that caused problems at runtime. This update adds extra check to avoid creating self-closing i18n instructions (create i18nStart and i18nEnd instructions instead) when styling instructions are present.
PR Close#27330
Previously the concept of multiple directives with the same selector was
not supported by ngtsc. This is due to the treatment of directives for a
component as a Map from selector to the directive, which is an erroneous
representation.
Now the directives for a component are stored as an array which supports
multiple directives with the same selector.
Testing strategy: a new ngtsc_spec test asserts that multiple directives
with the same selector are matched on an element.
PR Close#27298
These tests are not relevant to Ivy:
//packages/compiler-cli/test/diagnostics:check_types
//packages/compiler-cli/test/diagnostics:expression_diagnostics
//packages/compiler-cli/test/transformers:test
//packages/compiler-cli/test:extract_i18n
The //packages/compiler-cli/test:ngtools_api test has 2 specs, one of
which passes and the other of which depends on ngtsc supporting lazy
routes. It's now disabled with fixmeIvy().
PR Close#27301
In a more specific scenario: Considering people use a custom TypeScript compiler host with `NGC`, they _could_ expect only posix paths in methods like `writeFile`. This at first glance sounds like a trivial issue that should be just fixed by the actual compiler host, but usually TypeScript internal API's just pass around posix normalized paths, and therefore it would be good to follow the same standards when passing JSON genfiles to the `CompilerHost`.
For normal TypeScript files (and TS genfiles), this is already consistent because those will be handled by the actual TypeScript `Program` (see `emitCallback`).
PR Close#27062
This commit causes a call to setClassMetadata() to be emitted for every
type being compiled by ngtsc (every Angular type). With this metadata,
the TestBed should be able to recompile these classes when overriding
decorator information.
Testing strategy: Tests in the previous commit for
generateSetClassMetadataCall() verify that the metadata as generated is
correct. This commit enables the generation for each DecoratorHandler,
and a test is added to ngtsc_spec to verify all decorated types have
metadata generated for them.
PR Close#26860
* No longer depends on a custom CircleCI docker image that comes with Bazel pre-installed. Since Bazel is now available through NPM, we should be able to use the version from `@bazel/bazel` in order to enforce a consistent environment on CI and locally.
* This also reduces the amount of packages that need to be published (ngcontainer is removed)
PR Close#26691
We are close enough to blacklist a few test targets, rather than whitelist targets to run...
Because bazel rules can be composed of other rules that don't inherit tags automatically,
I had to explicitly mark all of our ts_library and ng_module targes with "ivy-local" and
"ivy-jit" tags so that we can create a query that excludes all fixme- tagged targets even
if those targets are composed of other targets that don't inherit this tag.
This is the updated overview of ivy related bazel tags:
- ivy-only: target that builds or runs only under ivy
- fixme-ivy-jit: target that doesn't yet build or run under ivy with --compile=jit
- fixme-ivy-local: target that doesn't yet build or run under ivy with --compile=local
- no-ivy-jit: target that is not intended to build or run under ivy with --compile=jit
- no-ivy-local: target that is not intended to build or run under ivy with --compile=local
PR Close#26471
This commit adds generation of .ngsummary.js shims alongside .ngfactory.js
shims when generated files are enabled.
Generated .ngsummary shims contain a single, null export for every exported
class with decorators that exists in the original source files. Ivy code
does not depend on summaries, so these exist only as a placeholder to allow
them to be imported and their values passed to old APIs. This preserves
backwards compatibility.
Testing strategy: this commit adds a compiler test to verify the correct
shape and contents of the generated .ngsummary.js files.
PR Close#26495
The 'animations' field of @Component metadata should be copied directly
into the ngComponentDef for that component and should not pass through
static resolution.
Previously the animations array was statically resolved and then the
values were translated back when generating ngComponentDef.
PR Close#26322
This commit builds on the NgtscTestEnvironment helper work before and
introduces template_typecheck_spec.ts, which contains compiler tests
for template type-checking.
PR Close#26203
This commit gets ready for the introduction of ngtsc template
type-checking tests by refactoring test environment setup into a
custom helper. This helper will simplify the authoring of future
ngtsc tests.
Ngtsc tests previously returned a numeric error code (a la ngtsc's CLI
interface) if any TypeScript errors occurred. The helper has the
ability to run ngtsc and return the actual array of ts.Diagnostics, which
greatly increases the ability to write clean tests.
PR Close#26203
Previously in Ivy, metadata for directives/components/modules/etc was
carried in .d.ts files inside type information encoded on the
DirectiveDef, ComponentDef, NgModuleDef, etc types of Ivy definition
fields. This works well, but has the side effect of complicating Ivy's
runtime code as these extra generic type parameters had to be specified
as <any> throughout the codebase. *DefInternal types were introduced
previously to mitigate this issue, but that's the wrong way to solve
the problem.
This commit returns *Def types to their original form, with no metadata
attached. Instead, new *DefWithMeta types are introduced that alias the
plain definition types and add extra generic parameters. This way the
only code that needs to deal with the extra metadata parameters is the
compiler code that reads and writes them - the existence of this metadata
is transparent to the runtime, as it should be.
PR Close#26203
`TypeScript` only supports merging and extending of `compilerOptions`. This is an implementation to support extending and inheriting of `angularCompilerOptions` from multiple files.
Closes: #22684
PR Close#22717
The bootstrap property of @NgModule was not previously compiled by
the compiler in AOT or JIT modes (in Ivy). This commit adds support
for bootstrap.
PR Close#25775
Closure requires @nocollapse on Ivy definition static fields in order
to not convert them to standalone constants. However tsickle, the tool
which would ordinarily be responsible for adding @nocollapse, doesn't
properly annotate fields which are added synthetically via transforms.
So this commit adds @nocollapse by applying regular expressions against
code during the final write to disk.
PR Close#25775
In tsc 3.0 the check that enables program structure reuse in tryReuseStructureFromOldProgram has changed
and now uses identity comparison on arrays within CompilerOptions. Since we recreate the options
on each incremental compilation, we now fail this check.
After this change the default set of options is reused in between incremental compilations, but we still
allow options to be overriden if needed.
PR Close#25275
This fixes a bug in ngtsc where each @Directive was compiled using a
separate ConstantPool. This resulted in two issues:
* Directive constants were not shared across the file
* Extra statements from directive compilation were dropped instead of
added to the file
This commit fixes both issues and adds a test to verify @Directive is
working properly.
PR Close#25620