fix(package): use exact uglify-es version (dependencies)

[jdubois]

This is for fixing the uglify-es dependency, as the new 3.3.x versions breaks up all Angular builds.

See here for Angular and here for Angular CLI

[jsf-clabot]

All committers have signed the CLA.

[alexander-akait]

Please update lock file

[michael-ciniawsky]

Is this angular specific or did uglify-es >= v3.3.0 break something in general ? What is the root cause of this bug(s) ?

[joshwiens]

@michael-ciniawsky - Doesn't really matter. It's breaking a major integration, we will pin it in the short term & sort it out later.

I'll update the lock file

[jdubois]

Thanks a lot @d3viant0ne

[sokra]

This is not how something like that should be handled. This package just passes through uglify-es behavior. If some uglify-es version is broken for you, you can lock it's version in your application lockfile (or package.json for a library).

[filipesilva]

@sokra I don't think there's a way for users to lock a specific version of a subdependency, at least with NPM. There are peer dependencies, but uglify-es is not a peer dependency of uglifyjs-webpack-plugin.

For Angular CLI users what happened is that they updated their lockfile, and got [email protected] in it and in npm cache. From this point on the only way they could force the lockfile to use [email protected] was:

• force a top-level uglify-es and hope hoisting works: npm i [email protected] --save-exact && rm -rf package-lock.json node_modules && npm i && npm ls uglify-es (relying on hoisting is problematic since different package managers do it differently)
• manually editing package-lock.json which requires a lot of knowledge about its inner working:

    "uglifyjs-webpack-plugin": {
      "version": "1.1.5",
      "resolved": "https://registry.npmjs.org/uglifyjs-webpack-plugin/-/uglifyjs-webpack-plugin-1.1.5.tgz",
      "integrity": "sha512-YBGc9G7dv12Vjx8vUQs54DZgAXVf04LlG6dNNiEbTZjL3PbUqiY4uPB9Kv+fUJaqRskEGva/lS7sh08yJr7jnA==",
      "dev": true,
      "requires": {
        "cacache": "10.0.1",
        "find-cache-dir": "1.0.0",
        "schema-utils": "0.3.0",
        "serialize-javascript": "1.4.0",
        "source-map": "0.6.1",
        "uglify-es": "3.2.2",
        "webpack-sources": "1.1.0",
        "worker-farm": "1.5.2"
      },
      "dependencies": {
        "uglify-es": {
          "version": "3.2.2",
          "resolved": "https://registry.npmjs.org/uglify-es/-/uglify-es-3.2.2.tgz",
          "integrity": "sha512-l+s5VLzFwGJfS+fbqaGf/Dfwo1MF13jLOF2ekL0PytzqEqQ6cVppvHf4jquqFok+35USMpKjqkYxy6pQyUcuug==",
          "dev": true,
          "requires": {
            "commander": "2.12.2",
            "source-map": "0.6.1"
          }
        }
      }
    },
// ...
    "uglify-es": {
      "version": "3.3.2",
      "resolved": "https://registry.npmjs.org/uglify-es/-/uglify-es-3.3.2.tgz",
      "integrity": "sha512-g7rGvx7YiFROLXKUtFMTw+YpTVV/XXPNvDUQfzwDTcB3vINwLUr3qXnkcPCu8VCIVjxI2EqaZ+sHoAxcYE/98w==",
      "requires": {
        "commander": "2.12.2",
        "source-map": "0.6.1"
      }
    },

I don't think either option is good for users.

I wouldn't say uglifyjs-webpack-plugin just passes on uglify-es behaviour either, because from a uglifyjs-webpack-plugin user POV they have no control over uglify-es. So if there's a problem with uglify-es it is wholly reflected on the behaviour of uglifyjs-webpack-plugin while the problematic versions remain within allowed semver ranges.

The way to express that sort of relationship is peer dependencies, but I don't think that's very ergonomic. If we were to use peer dependencies for every webpack plugin then there would a lot more maintenance work involved in updating versions. Sass loader adopted that approach though (webpack-contrib/sass-loader#519).

Maybe having X-loader always have a peer dependency on X is the right way to address cases like this within NPM.

[filipesilva]

FYI I opened a feature request in npm for a wait to set indirect dependency versions: npm/npm#19512