Instead of relying on Microsoft's API extractor for `d.ts` bundling,
we are switching to Rollup-based `.d.ts` bundling.
This allows us to support code spliting, even for `.d.ts` files,
allowing for relative imports to be used between entry-points, without
ending up duplicating `.d.ts` definitions in two files. This would otherwise cause
problems with assignability of types.
It also nicely integrates into our existing rollup configuration, and
overall simplifies the `ng_package` rule even further!
Notably `tsup` also uses this rollup plugin, and it seems to work well.
Keep in mind that Microsoft's API extractor is pretty hard to integrate,
caused many problems in the past, and isn't capable of code splitting.
This aligns our d.ts bundling with the .mjs bundling (great alignment).
PR Close#60321
Currently the language service has some template-specific terminology around type checking, because that's the only place where we had TCB support. These changes make it more generic to accommodate future functionality.
PR Close#60191
Currently only components can have resources, because they're the only symbol kinds being type checked. Since we want to add directives to it, these changes rework the resource handling to accommodate them.
PR Close#60191
Currently the `TemplateSourceManager` is set up to specifically cater to component templates. These changes make it more generic so we can reuse it for directives.
PR Close#60191
Prior to this commit, the tags from the type definition were dropped.
Tags may include, but are not limited to, deprecation information from
the jsdoc.
PR Close#59524
Add support for the `void` operator in templates and host bindings.
This is useful when binding a listener that may return `false` and
unintentionally prevent the default event behavior.
Ex:
```
@Directive({
host: { '(mousedown)': 'void handleMousedown()' }
})
```
BREAKING CHANGE: `void` in an expression now refers to the operator
Previously an expression in the template like `{{void}}` referred to a
property on the component class. After this change it now refers to the
`void` operator, which would make the above example invalid. If you have
existing expressions that need to refer to a property named `void`,
change the expression to use `this.void` instead: `{{this.void}}`.
PR Close#59894
In the past two-way bindings used to be interpreted as `foo = $event` at the parser level. In #54065 it was changed to preserve the actual expression, because it was problematic for supporting two-way binding to signals. This unintentionally ended up causing the TCB to two-way bindings to look something like `someOutput.subscribe($event => expr);` which does nothing. It largely hasn't been a problem, because the input side of two-way bindings was still being checked, except for the case where the input side of the two-way binding has a wider type than the output side.
These changes re-add type checking for the output side by generating the following TCB instead:
```
someOutput.subscribe($event => {
var _t1 = unwrapSignalValue(this.someField);
_t1 = $event;
});
```
PR Close#59002
The error codes that have fixes are present in a Map instance and
can be directly leveraged to determine if an error code can be fixed.
This avoids multiple levels of iteration that would otherwise be needed.
PR Close#58759
Fixes that `getCodeActions` wasn't implemented for the unused imports fixer which meant that it wouldn't show up in the most common cases.
PR Close#58719
Currently the code fixes won't run if the template information can't be resolved on the diagnostic node. This is incorrect for diagnostics that are reported within `.ts` files. These changes make the `templateInfo` nullable and leave the early exit up to the individual fixes.
PR Close#58719
Initially the unused imports check was implemented so that it reports one diagnostic per component with the individual unused imports being highlighted through the `relatedInformation`. This works fine when reporting errors to the command line, but vscode appears to only show `relatedInformation` when the user hovers over a diagnostic which is a sub-par experience.
These changes switch to reporting a diagnostic for each unused import instead.
PR Close#58589
When setting `"useDefineForClassFields": false`, static fields are compiled within a block that relies on the `this` context. This output makes it more difficult for bundlers to treeshake and eliminate unused code.
PR Close#58297
This is necessary given the previous Tsurge refactorings. It should
speed up migrations in the merge phase signficiantly and reduce memory
pressure. In 1P, we already have workers from analyze phase anyway— so
those can be re-used for parallel metadata merging.
PR Close#58280
This is necessary given the previous Tsurge refactorings. It should
speed up migrations in the merge phase signficiantly and reduce memory
pressure. In 1P, we already have workers from analyze phase anyway— so
those can be re-used for parallel metadata merging.
PR Close#58280
This is a follow-up to the VSCode queries code refactoring feature. This
commit adds support for running the refactoring with
`--best-effort-mode`.
PR Close#58168
Instead of skipping queries without any reasoning, we should categorize
fields that couldn't be migrated. This is also important for the VSCode
integration— similar to how it's done with the inputs migration.
We are fully sharing the problematic pattern detection etc. This means
we are also sharing the enum. Not super ideal, but enables the best
sharing of code.
PR Close#58152
This commit moves the incompatibility categorization into a more common
place, and renames it from Input incompatibilities to "field
incompatibilities". This construct can then be used in the queries
migration as well to give insight into why certain fields weren't
migrated.
PR Close#58139
This commit adds support for converting decorator queries to signal queries
via the VSCode extension.
Note that this is not fully finished as we still need to add better
messaging when certain fields could not be migrated.
In addition, it's worth noting that the migration is not as safe as the
input migration because commonly query lists are passed around— this
quickly can break the build— but is an acceptable trade-off for the work
saved. A migration cannot be 100% correct in general; there are always
edge-cases.
PR Close#58106
This allows us to return extra properties along with `#migrate`
replacements. Useful for language service integration or other
integrations of Tsurge migrations in special runners.
PR Close#58106
In order to investigate the performances of SSR, this commit introduces a benchmark suite which will measure several step of the rendering.
PR Close#57647
This commit expands the VScode integration of the signal input migration
to allow migration of full classes and all their inputs. This enables a
faster workflow than just migrating every member individually.
In addition, we now properly support migrating classes that are
unexported and no actual metadata is available in `ngtsc` (but this is
fine for the migration).
PR Close#57975
Finalizes compiler implementation of the new `hydrate` triggers by:
* Reworking the logic that was depending on the `hydrateSpan` to distinguish hydrate triggers from non-hydrate triggers.
* Fixing that the `hydrate when` trigger didn't have a `hydrateSpan`.
* Adding an error if a parameter is passed into a `hydrate` trigger.
* Add an error if other `hydrate` triggers are used with `hydrate never`.
* Replacing the `prefetch` and `hydrate` flags in the template pipeline with a `modifiers` field.
* Fixing an error that was being thrown when reifying `hydrate` triggers in the pipeline.
* Adding quick info support for the `hydrate` keyword in the language service.
* Adding some tests for the new logic.
PR Close#57831
Whenever the `ngc` binary is used directly to parse configurations, we
should try to respect the configured file system like we do in all other
places. Right now one spot where we escape the FS is for reading
directories to e.g. support tsconfig#includes.
This commit fixes this, implementing TypeScript's read directory method
leveraging the configured FS. The approach taken here was used for a
couple of months/years for Angular Material migrations and no issues
were found.
PR Close#57805
Migrations may resolve files in e.g. `blaze-out` and try to compute a
path for the file that is "recognizable" across workers. E.g. in one
worker, it may be the actual `.ts` file inside the source tree, while in
the other, the file may be inside `blaze-out`.
Tsurge currently expects project relative paths to be passed around.
Those project relative paths are currently only based on the single root
directory. Hence paths inside `blaze-out` would actually not be
recognizable.
The fix idea here is that we introduce a structure for Project files.
This structure will contain two fields:
- an ID of a file. This is similar to a module ID in the project. Those
are resolved with respect to all root directories. This matches the
conceptual virtual roots of `tsconfig#rootDirs`. The IDs can be used
for matching files across workers, assuming those are executing using
the same root directories, and handle the same overall project (e.g.
google3).
- a path relative to the primary project root. Multiple roots may be
configured, but the primary project root, is the directory that
contains all others. See: `tsconfig.rootDir`. This path is NOT
necessarily useful for matching files between stages etc, but it's
useful for writing replacements for a given file to disk.
Note that those two things cannot be combind into one conceptual
"project relative path" because a path relative to the most appropriate
root directory cannot be used for safe replacements. E.g. consider a
replacement matches a file from a root directory like `/sub/`. The path
inside `/sub/` would then omit the `/sub/` and later on when writing
replacements, we wouldn't know which root directory it actually was part
of. Hence the concept of a "project root relative path" and the "ID".
ds
PR Close#57677
Add a check to the language service that ignores specified diagnostic codes. This will be useful in g3.
The codes to ignore are exposed as part of the PluginConfig.
Fixes github.com/angular/vscode-ng-language-service/issues/1243
PR Close#57675
Currently the import manager always add a space after the import clause
brace. We should only do this if the existing import did the same.
PR Close#57672
Instead of printing the enum name as the reason why migration did not
complete, we should print some human-readable descriptions.
This commit implements this. This logic may also be useful for the
devkit comment generation, or CLI usage.
In addition, we expose another VSCode refactoring to try via best effort
mode. There is no way for prompting, or adding multiple actions for the
same refactoring, so we expose a new refactoring.
PR Close#57659
