asset-plugin can not satisfy constraint, while npm/yarn silently upgrade

[schmunk42]

Due to issues with an npm-asset I tried to debug it with yarn install mermaid

Giving me those packages:

success Saved 20 new dependencies.
├─ ansi-styles@3.2.0
├─ chalk@2.1.0
├─ color-convert@1.9.0
├─ color-name@1.1.3
├─ d3@3.5.17
├─ dagre-d3-renderer@0.4.18
├─ dagre@0.7.4
├─ escape-string-regexp@1.0.5
├─ graphlib@1.0.7
├─ has-flag@2.0.0
├─ he@1.1.1
├─ isexe@2.0.0
├─ lodash@3.10.1
├─ mermaid@7.0.8
├─ minimist@1.2.0
├─ mkdirp@0.5.1
├─ moment@2.18.1
├─ semver@5.4.1
├─ supports-color@4.4.0
└─ which@1.3.0

But mkdirp 0.5.1 says mininist 0.0.8 https://github.com/substack/node-mkdirp/blob/0.5.1/package.json But I get 1.2.0 above.

With fxp I get:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: don't install npm-asset/mermaid 7.0.6
    - Conclusion: don't install npm-asset/mermaid 7.0.7
    - Conclusion: don't install npm-asset/mermaid 7.0.8
    - Can only install one of: npm-asset/minimist[1.2.0, 0.0.8].
    - npm-asset/mkdirp 0.5.1 requires npm-asset/minimist 0.0.8 -> satisfiable by npm-asset/minimist[0.0.8].
    - npm-asset/mermaid 7.0.5 requires npm-asset/minimist >=1.2.0,<2.0.0 -> satisfiable by npm-asset/minimist[1.2.0].
    - npm-asset/mermaid 7.0.5 requires npm-asset/mkdirp >=0.5.1,<0.6.0 -> satisfiable by npm-asset/mkdirp[0.5.1].
    - Installation request for npm-asset/mermaid ^7.0.5 -> satisfiable by npm-asset/mermaid[7.0.5, 7.0.6, 7.0.7, 7.0.8].

Seems like this is "normal" in the npm/yarn ecosystem :( Since many projects are dropping bower support, it might be necessary to switch to npm, but how to tackle this issue? Could fxp "fix" that also?

CC: @cebe @samdark This influences Yii 2 extensions to a great extend.

[francoispluchino]

Because NPM/Yarn can install multiple version of the same library, but that Composer can only have a single version for the same library (flat dependency):

mkdirp require minimist: 0.0.8 and mermaid require minimist: 1.2.0

The plugin is capable of obtaining several versions of the same library, but not for the resolution of conflicts.

Currently the plugin can resolve conflicts like Bower (in config and with only single version of dependency).

[francoispluchino]

You can see the doc Solve the conflicts of asset dependencies.

[francoispluchino]

Interesting point for Yarn, it is able to create a flat dependencies with the option --flat. It is for this reason that Polymer's team uses Yarn instead of NPM for version 3.0.

Try:

$ yarn add mermaid --flat

And you obtains a wizard to solve the conflicts for: lodash, minimist, and graphlib.

[schmunk42]

I am just playing around with those and it looks to me like it is virtually impossible to do flat installations even on a single package (mermaid in my case) without manually solving conflicts.

I just learned today about peerDependencies of npm I wonder why they were never mentioned here before.

But aren't those peerDependencies the actual dependencies fxp should parse and do depedency resolution with, when handling npm packages? To my understanding, you can only have one peerDependency in a project, while you can have many "normal" (private) dependencies with npm.

For sure, when bundling js/css you'd need another tool then...

[francoispluchino]

peerDependencies is very little used. And for this plugin, it's not necessary because Composer already requires the same compatible version of a dependency.

To solve the resolution of dependencies, you must use the config.fxp-asset.resolutions option. Unfortunately, it is not possible to make a wizard like Yarn to select the good version.

[schmunk42]

And for this plugin, it's not necessary because Composer already requires the same compatible version of a dependency.

My problem is that there are so many projects, which simply do not resolve to a single version for a certain package. Since bower is deprecated and we will have to move to npm sooner or later, this will get worse. I don't think a manual resolution is feasible in the long term.

I'll close this issue since, it's not really fixable. But we should re-think assets for Yii 2.1