At the moment, we get patch updates for different major and minor versions than the current version of TypeScript installed.
```json
{
"packageRules": [
{
"packageNames": [
"typescript"
],
"separateMinorPatch": true
},
{
"packageNames": [
"typescript"
],
"updateTypes": [
"minor",
"major"
],
"enabled": false
}
]
}
```
What the first rule does is override Renovate's results so that if TypeScript has both a minor update as well as a patch update then you get both PRs. Renovate's default otherwise is to just give you the latest minor or squash. So for example if the current TypeScript is `3.4.4` then the default behaviour is just to PR you for `3.5.1`. With this rule, we get both `3.4.5` and `3.5.1`.
The second rule then disables major and minor updates for TypeScript, which has the effect of them suppressing the minor `3.5.1` update.
For more context see: https://github.com/renovatebot/config-help/issues/260
This ensures that migration fields that reference other packages use the package version specified in the migrating package's dependencies and not the version that a package manager happens to hoist to the root of the workspace.
With this change we wrap ClassDeclarations inside an IIFE, also we move some code from the class fold into the wrap-enums.
This changes the below code:
```js
export class Foo {
method() {
}
}
Foo.bar = 'barValue';
__decorate([
methodDecorator
], Foo.prototype, "method", null);
```
to
```js
export const Foo = /*@__PURE__*/ (() => {
class Foo {
method() {
}
}
Foo.bar = 'barValue';
__decorate([
methodDecorator
], Foo.prototype, "method", null);
return Foo;
})();
```
Fixes#14610
ClassExpressions such as the below are not treeshakable unless we wrap them in an IIFE
```js
let AggregateColumnDirective = class AggregateColumnDirective {
constructor(viewContainerRef) { }
};
AggregateColumnDirective = __decorate([
Directive({}),
__metadata("design:paramtypes", [ViewContainerRef])
], AggregateColumnDirective);
```
With this change we wrap the above in an IIFE and mark it as a PURE function.
```js
const AggregateColumnDirective = /*@__PURE__*/ (() => {
let AggregateColumnDirective = class AggregateColumnDirective {
constructor(viewContainerRef) { }
};
AggregateColumnDirective = __decorate([
Directive({}),
__metadata("design:paramtypes", [ViewContainerRef])
], AggregateColumnDirective);
return AggregateColumnDirective;
})();
```
With this pattern if the class is unused it will be dropped.
Note: In future we should rename `wrap-enums` to something more generic, and combine class-fold with this transformer especially considering the future fix that needs to be done for https://github.com/angular/angular-cli/issues/14610Fixes#14577
Testing on AIO with Angular master as of 28/05/2019 I got these results:
JIT ~414ms (369, 378, 408, 323, 593)
AOT using VE ~1383ms (1365, 1185, 1767, 1135, 1467)
AOT using Ivy ~517ms (600, 391, 444, 756, 394)
This is largely due to https://github.com/angular/angular/pull/29380 and https://github.com/angular/angular/pull/30238.
The second PR above was not merged to master, and thus will not be in 8.0.0. This PR should be merged to match it.
`@ngtools/webpack` only supports compiler version 8 as per the peerDependency.
The fixes the `isSupported` version static and also removes code that was to support prior versions of compiler-cli
In the CLI `UpdateRecorder` methods such as `insertLeft`, `remove` etc.. accepts positions which are not offset by a BOM. This is because when a file has a BOM a different recorder will be used https://github.com/angular/angular-cli/blob/master/packages/angular_devkit/schematics/src/tree/recorder.ts#L72 which caters for an addition offset/delta.
The main reason for this is that when a developer is writing a schematic they shouldn't need to compute the offset based if a file has a BOM or not and is handled out of the box.
Example
```ts
recorder.insertLeft(5, 'true');
```
However this is unfortunate in the case if a ts SourceFile is used and one uses `getWidth` and `getStart` method they will already be offset by 1, which at the end it results in a double offset and hence the problem.
Fixes#14551
With Angular CLI version 8, migrations cannot be re-run with the
`--migrate-only` flag as there was a recent regression introduced
in e406f00909 (diff-0d0a748fb9a38a7ccde08d9b42e70bce) as it now passes
a normalized platform path to the `engine.createCollection` call.
This breaks as there is incorrect logic within
`node-modules-engine-host` that causes the schematic collection to be
searched within the `package.json#schematics` entry. This is incorrect
as migration schematics specify their migration schematics in a separate
schematic collection file which is part of `package.json#ng-update`.
Fixes#14565
