If a template contains specific TypeScript syntax, such as a non-null
assertion, the code that is emitted from ngcc into a JavaScript bundle
should not retain such syntax as it is invalid in JS.
A full-blown TypeScript emit of a complete ts.SourceFile would be
required to be able to emit JS and possibly downlevel into a lower
language target, which is not an option for ngcc as it currently
operates on partial ASTs, not full source files.
Instead, ngtsc no longer produces TypeScript specific syntax in the first
place, such that TypeScript print logic will only generate JS code.
PR Close#27051
Ngcc will now render additional exports for classes that are referenced in
`NgModule` decorated classes, but which were not publicly exported
from an entry-point of the package.
This is important because when ngtsc compiles libraries processed by ngcc
it needs to be able to publcly access decorated classes that are referenced
by `NgModule` decorated classes in order to build templates that use these
classes.
Doing this re-exporting is not without its risks. There are chances that
the class is not exported correctly: there may already be similarly named
exports from the entry-point or the class may be being aliased. But there
is not much more we can do from the point of view of ngcc to workaround
such scenarios. Generally, packages should have been built so that this
approach works.
PR Close#26906
There are a number of variables that need to be passed around
the program, in particular to the renderers, which benefit from being
stored in well defined objects.
The new `EntryPointBundle` structure is a specific format of an entry-point
and contains the compiled `BundleProgram` objects for the source and typings,
if appropriate.
This change helps with future refactoring, where we may need to add new
properties to this object. It allows us to maintain more stable APIs between
the constituent parts of ngcc, rather than passing lots of primitive values
around throughout the program.
PR Close#26906
The `NgModuleDecoratorHandler` can now register all the references that
it finds in the `NgModule` metadata, such as `declarations`, `imports`,
`exports` etc.
This information can then be used by ngcc to work out if any of these
references are internal only and need to be manually exported from a
library's entry-point.
PR Close#26906
When ngtsc compiles @angular/core, it rewrites core imports to the
r3_symbols.ts file that exposes all internal symbols under their
external name. When creating the FESM bundle, the r3_symbols.ts file
causes the external symbol names to be rewritten to their internal name.
Under ngcc compilations of FESM bundles, the indirection of
r3_symbols.ts is no longer in place such that the external names are
retained in the bundle. Previously, the external name `ɵdefineNgModule`
was explicitly declared internally to resolve this issue, but the
recently added `setClassMetadata` was not declared as such, causing
runtime errors.
Instead of relying on the r3_symbols.ts file to perform the rewrite of
the external modules to their internal variants, the translation is
moved into the `ImportManager` during the compilation itself. This
avoids the need for providing the external name manually.
PR Close#27055
For each package entry-point there is only one format that
is used to compile the typings files (.d.ts). This will be
either esm2015 or fesm2015 (preferred). So we would not run
any dts processing in the renderer if we are not compiling
the appropriate format.
PR Close#26403
1) The `DecorationAnalyzer now analyzes all source files, rather than just
the entry-point files, which fixes#26183.
2) The `DecoratorAnalyzer` now runs all the `handler.analyze()` calls
across the whole entry-point *before* running `handler.compile()`. This
ensures that dependencies between the decorated classes *within* an
entry-point are known to the handlers when running the compile process.
3) The `Renderer` now does the transformation of the typings (.d.ts) files
which allows us to support packages that only have flat format
entry-points better, and is faster, since we won't parse `.d.ts` files twice.
PR Close#26403
The rendering of typings is not specific to the package
format, so it doesn't make sense to put it in a specific
renderer.
As a result there is no real difference between esm5 and esm2015
renderers, so there is no point in having separate classes.
PR Close#26403
Going forward we need to be able to do the same work on both
flat and non-flat module formats (such as computing arity and
transforming .d.ts files)
PR Close#26403
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
Closure compiler requires that the i18n message constants of the form
const MSG_XYZ = goog.getMessage('...');
have names that are unique across an entire compilation, even if the
variables themselves are local to a given module. This means that in
practice these names must be unique in a codebase.
The best way to guarantee this requirement is met is to encode the
relative file name of the file into which the constant is being written
into the constant name itself. This commit implements that solution.
PR Close#25689
This commit creates an API for factory functions which allows them
to be inherited from one another. To do so, it differentiates between
the factory function as a wrapper for a constructor and the factory
function in ngInjectableDefs which is determined by a default
provider.
The new form is:
factory: (t?) => new (t || SomeType)(inject(Dep1), inject(Dep2))
The 't' parameter allows for constructor inheritance. A subclass with
no declared constructor inherits its constructor from the superclass.
With the 't' parameter, a subclass can call the superclass' factory
function and use it to create an instance of the subclass.
For @Injectables with configured providers, the factory function is
of the form:
factory: (t?) => t ? constructorInject(t) : provider();
where constructorInject(t) creates an instance of 't' using the
naturally declared constructor of the type, and where provider()
creates an instance of the base type using the special declared
provider on @Injectable.
PR Close#25392
Previously, ngtsc used a new ConstantPool for each decorator
compilation. This could result in collisions between constants in the
top-level scope.
Now, ngtsc uses a single ConstantPool for each source file being
compiled, and merges the constant statements into the file after the
import section.
PR Close#25392
To match the View Engine behavior.
We should make this configurable so that the node injector is tree shaken when
directives do not need to be published.
PR Close#25291
JoostK
Pete Bacon Darwin
Alex Rickabaugh
Marc Laval
George Kalpakas
Victor Berchet