Build optimizer breaks third party libraries

From @yGuy on April 3, 2018 11:56

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Area

- [x] devkit
- [ ] schematics

Versions

all

Repro steps

• Scaffold a project that uses code (e.g. a third party library) that contains code that cannot be properly “optimized” using uglifyjs. E.g. code that uses “non-pure getters” like this:

let object = {};
Object.defineProperty(object,"nonSideEffectFreeGetterBasedMember", 
    {get: function(){ console.log("side effect")}});

(function () {
  object.nonSideEffectFreeGetterBasedMember;
}());

• Enable the angular build optimizer
• Run the program with the build optimizer enabled and observe that the code does not work as expected anymore, because the non-pure getter has been removed and the side-effect does not happen anymore.

The log given by the failure

n/a

Desired functionality

It should be possible to either configure the build optimizer and disable possibly logic-breaking optimizations altogether or at least on a per dependency basis. Especially if the third party library is already optimized/minified/preprocessed the danger of breaking things is higher than the benefits of possibly saving a few more bytes.

Mention any other details that might be useful

Right now it is an either/or - either the code runs and you can rely on it, or it may be “optimized” but broken in some cases.

The tool-chain makes it easy to include all kind of packages from third parties via npm, etc. The “build-optimizer” cannot dictate how the code of all of these packages needs to be written in order to work with the “optimization” step. It’s OK to forbid non-pure getters in the angular code base, but not in any third party code. Either add an option to only apply safe code transformations for third party code or make this an opt-in. The binary API right now is not sufficient.

Copied from original issue: angular/devkit#612

[yGuy]

That’s wrong - it should be:

“If a library is side effect free it may specify this in its package.json using sideEffects false”

Node module authors should not be forced to indicate that they are using valid ecmascript features. As an optimization, if they are not using a specific feature, they could indicate this to help tools that may optimize for this specific situation, but having to list valid features from the spec that you are using and assuming that they are not being used if they are not listed is just plain stupid and ignorant. The problem is the build “optimizer” that breaks the code, not the code that has not been written to workaround issues in the build optimizer. Closing issues without a resolution to the actual problem and blaming others for their valid usage of a language feature does not make this any more correct.

It’s still JavaScript in NPM, not AngularScript or GoogleScript. Feel free to make the build optimizer require AngularScript instead, but then clearly document this and tell the world that this is not a JavaScript tool, but an AngularScript tool which only works with AngularScript.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}