Skip to content

fix(@angular-devkit/build-angular): exclude @angular/platform-server/init from unsafe optimizations #25083

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
angular-robot merged 1 commit into from
Apr 27, 2023
Merged

fix(@angular-devkit/build-angular): exclude @angular/platform-server/init from unsafe optimizations #25083

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 6 additions & 3 deletions packages/angular_devkit/build_angular/src/babel/webpack-loader.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -154,12 +154,15 @@ export default custom<ApplicationPresetOptions>(() => {
}

if (optimize) {
const angularPackage = /[\\/]node_modules[\\/]@angular[\\/]/.test(this.resourcePath);
// @angular/platform-server/init entry-point has side-effects.
Copy link
Member

@devversion devversion Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about other side-effect entry-points? we might be adding arbitrary ones. Can't we rely on the sideEffects field in package.json? We also have localize/init IIRC (but yes- that one is usually not in user code I think)

Copy link
Member

@clydin clydin Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once we move this into the actual FW packaging and bundling process, these checks can all be removed.
Also, adding any side effect entry points should be done with care since import statement usage then can become order dependent. As well as also causing deoptimizations in other aspects of the build pipeline.

Copy link
Collaborator Author

@alan-agius4 alan-agius4 Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@angular/localize/init is not in users code indeed.

Copy link
Member

@devversion devversion Apr 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes exactly, just need to be careful in adding new entry-points. I don't think the current solution is ideal (and I'm not aware of the concrete plans going forward)

const safeAngularPackage =
/[\\/]node_modules[\\/]@angular[\\/]/.test(this.resourcePath) &&
!/@angular[\\/]platform-server[\\/]f?esm2022[\\/]init/.test(this.resourcePath);
customOptions.optimize = {
// Angular packages provide additional tested side effects guarantees and can use
// otherwise unsafe optimizations.
looseEnums: angularPackage,
pureTopLevel: angularPackage,
looseEnums: safeAngularPackage,
pureTopLevel: safeAngularPackage,
// JavaScript modules that are marked as side effect free are considered to have
// no decorators that contain non-local effects.
wrapDecorators: !!this._module?.factoryMeta?.sideEffectFree,
Expand Down