Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

ember-cli install weirdness #7552

Closed
isaacs opened this issue Mar 5, 2015 · 13 comments
Closed

ember-cli install weirdness #7552

isaacs opened this issue Mar 5, 2015 · 13 comments
Assignees

Comments

@isaacs
Copy link
Contributor

isaacs commented Mar 5, 2015

When you take the package.json generated by ember-cli's ember new app, and then try to npm install with it, you get a broken state:

{
  "name": "app",
  "version": "0.0.0",
  "description": "Small description for app goes here",
  "private": true,
  "directories": {
    "doc": "doc",
    "test": "tests"
  },
  "scripts": {
    "start": "ember server",
    "build": "ember build",
    "test": "ember test"
  },
  "repository": "",
  "engines": {
    "node": ">= 0.10.0"
  },
  "author": "",
  "license": "MIT",
  "devDependencies": {
    "broccoli-asset-rev": "^2.0.0",
    "ember-cli": "0.2.0-beta.1",
    "ember-cli-babel": "^4.0.0",
    "ember-cli-app-version": "0.3.1",
    "ember-cli-content-security-policy": "0.3.0",
    "ember-cli-dependency-checker": "0.0.7",
    "ember-cli-htmlbars": "0.7.4",
    "ember-cli-ic-ajax": "0.1.1",
    "ember-cli-inject-live-reload": "^1.3.0",
    "ember-cli-qunit": "0.3.8",
    "ember-cli-uglify": "1.0.1",
    "ember-data": "1.0.0-beta.15",
    "ember-export-application-global": "^1.0.2",
    "express": "^4.8.5",
    "glob": "^4.0.5"
  }
}
$ npm ls glob rimraf
npm WARN unmet dependency /Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/broccoli-caching-writer/node_modules/rimraf requires glob@'^4.4.2' but will load
npm WARN unmet dependency /Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/glob,
npm WARN unmet dependency which is version 4.0.5
npm WARN unmet dependency /Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/broccoli-es6modules/node_modules/broccoli-caching-writer/node_modules/rimraf requires glob@'^4.4.2' but will load
npm WARN unmet dependency /Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/glob,
npm WARN unmet dependency which is version 4.0.5
npm WARN unmet dependency /Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/broccoli-es6modules/node_modules/esperanto/node_modules/sander/node_modules/rimraf requires glob@'^4.4.2' but will load
npm WARN unmet dependency /Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/glob,
npm WARN unmet dependency which is version 4.0.5
npm WARN unmet dependency /Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/broccoli-sourcemap-concat/node_modules/broccoli-caching-writer/node_modules/rimraf requires glob@'^4.4.2' but will load
npm WARN unmet dependency /Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/glob,
npm WARN unmet dependency which is version 4.0.5
app@0.0.0 /Users/isaacs/dev/js/x/app
├─┬ broccoli-asset-rev@2.0.1
│ └─┬ broccoli-filter@0.1.11
│   ├─┬ broccoli-kitchen-sink-helpers@0.2.6
│   │ └── glob@4.0.4
│   └─┬ quick-temp@0.1.2
│     └── rimraf@2.2.8
├─┬ ember-cli@0.2.0-beta.1
│ ├─┬ bower@1.3.12
│ │ └── rimraf@2.2.8
│ ├─┬ broccoli@0.13.3
│ │ └─┬ findup-sync@0.1.3
│ │   └── glob@3.2.11
│ ├─┬ broccoli-caching-writer@0.5.1
│ │ ├─┬ broccoli-kitchen-sink-helpers@0.2.6
│ │ │ └── glob@4.0.4
│ │ ├─┬ quick-temp@0.1.2
│ │ │ └── rimraf@2.2.8
│ │ └── rimraf@2.3.1
│ ├─┬ broccoli-es6modules@0.5.1
│ │ ├─┬ broccoli-caching-writer@0.5.3
│ │ │ ├─┬ quick-temp@0.1.2
│ │ │ │ └── rimraf@2.2.8
│ │ │ └── rimraf@2.3.1
│ │ ├─┬ broccoli-kitchen-sink-helpers@0.2.6
│ │ │ └── glob@4.0.4
│ │ └─┬ esperanto@0.6.17
│ │   └─┬ sander@0.2.2
│ │     └── rimraf@2.3.1
│ ├─┬ broccoli-funnel@0.2.2
│ │ └── rimraf@2.2.8
│ ├─┬ broccoli-sourcemap-concat@0.4.3
│ │ ├─┬ broccoli-caching-writer@0.5.3
│ │ │ ├─┬ quick-temp@0.1.2
│ │ │ │ └── rimraf@2.2.8
│ │ │ └── rimraf@2.3.1
│ │ └─┬ broccoli-kitchen-sink-helpers@0.2.6
│ │   └── glob@4.0.4
│ ├─┬ broccoli-writer@0.1.1
│ │ └─┬ quick-temp@0.1.2
│ │   └── rimraf@2.2.8
│ ├─┬ fs-extra@0.12.0
│ │ └── rimraf@2.2.8
│ ├── glob@4.0.5  invalid
│ ├─┬ npm@2.1.8
│ │ ├── glob@4.0.6
│ │ └── rimraf@2.2.8
│ ├─┬ quick-temp@0.1.2
│ │ └── rimraf@2.2.8
│ ├─┬ temp@0.8.1
│ │ └── rimraf@2.2.8
│ ├─┬ testem@0.7.0
│ │ ├─┬ fileset@0.1.5
│ │ │ └── glob@3.2.11
│ │ ├── glob@4.3.5
│ │ └── rimraf@2.2.8
│ └─┬ yam@0.0.17
│   └─┬ fs-extra@0.8.1
│     └── rimraf@2.2.8
├─┬ ember-cli-babel@4.1.0
│ ├─┬ broccoli-babel-transpiler@4.0.1
│ │ └─┬ babel-core@4.6.6
│ │   └─┬ regenerator-babel@0.8.13-1
│ │     └─┬ commoner@0.10.1
│ │       └── glob@4.2.2
│ └─┬ broccoli-filter@0.1.11
│   ├─┬ broccoli-kitchen-sink-helpers@0.2.6
│   │ └── glob@4.0.4
│   └─┬ quick-temp@0.1.2
│     └── rimraf@2.2.8
├─┬ ember-cli-htmlbars@0.7.4
│ └─┬ broccoli-filter@0.1.11
│   ├─┬ broccoli-kitchen-sink-helpers@0.2.6
│   │ └── glob@4.0.4
│   └─┬ quick-temp@0.1.2
│     └── rimraf@2.2.8
├─┬ ember-cli-qunit@0.3.8
│ └─┬ broccoli-jshint@0.5.3
│   ├─┬ broccoli-filter@0.1.11
│   │ ├─┬ broccoli-kitchen-sink-helpers@0.2.6
│   │ │ └── glob@4.0.4
│   │ └─┬ quick-temp@0.1.2
│   │   └── rimraf@2.2.8
│   ├─┬ findup-sync@0.1.3
│   │ └── glob@3.2.11
│   └─┬ jshint@2.5.11
│     └─┬ cli@0.6.5
│       └── glob@3.2.11
├─┬ ember-cli-uglify@1.0.1
│ └─┬ broccoli-uglify-sourcemap@0.2.1
│   └─┬ broccoli-writer@0.1.1
│     └─┬ quick-temp@0.1.2
│       └── rimraf@2.2.8
└── glob@4.4.2

I think this might be a bug in how we're calculating the package ancestry while deciding what to install.

Note: rimraf@2.3.1 depends on glob@^4.4.2. If it gets any other version of glob, bad times happen.

At the top level, we have a dep on glob@^4.0.5. This resolves to 4.4.2, which is good.

Then, ember-cli is installed, which has a dep on glob@4.0.5, and it is a bundled dependency.

Underneath, ember-cli, we get broccoli-caching-writer@0.5.3, which depends on rimraf@^2.2.8.

I would expect that, since the closest ancestor glob is ember-cli's (bundled) glob@4.0.5, it should say, "Oh, this won't work for me". However, we're not getting another copy of glob@4.4.2 installed underneath rimraf here.

Then, this happens 2 more times, since broccoli-es6modules@0.5.1 and broccoli-sourcemap-concat@0.4.3 also depend on broccoli-caching-writer@0.5.3.

Is it failing to add the bundled glob to the ancestor set, and thinking that the root's glob@4.4.2 is the nearest ancestor?

@maxkwallace
Copy link

I'm running into this issue as well.

@jesuskwice
Copy link

Same here.. (ember-cli@0.1.12)

@intuitivepixel
Copy link

Same here on ember-cli@0.2.0-beta.1

@maxkwallace
Copy link

After searching around, I found #1341 which allowed me to figure out the following fix:

For each unmet dependency warning, run npm install in the directory of that dependency, e.g. for
npm WARN unmet dependency /Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/broccoli-caching-writer/node_modules/rimraf requires glob@'^4.4.2' but will load ...

Run npm install in
/Users/isaacs/dev/js/x/app/node_modules/ember-cli/node_modules/broccoli-caching-writer/node_modules/rimraf

In my case, this was because I had a top-level dependency on glob 4.0.5, which was preventing the child modules from receiving a copy of glob 4.4.2 or later.

Even if it's unfeasible to devise a full solution for this issue any time soon, it would be really great if npm included a block of explanatory help text that's printed out before any 'unmet dependency' errors, since lots of people seem to be running into this issue.

@s12chung
Copy link

ember-cli@0.1.12...

temporary solution is to keep the old version in package.json:
"rimraf": "2.3.0"

@topherbullock
Copy link

_EDIT_ Just saw @isaacs ' post in the original ember-cli thread clarifying that the fix is not to rollback rimraf , but to add "glob":"^4.4.2"1` to your root deps.

Could the problem be that NPM isn't identifying the ember-cli "middle-child" dependency for a specific static version of glob@4.0.5 as not satisfying rimraf's glob@^4.4.2 requirement because it looks higher up in the ancestry set and finds the root glob@^4.0.5?

NPM knows that it did a bad thing, because npm ls tells us specifically that rimraf is going to try and load the invalid glob@4.0.5 from ember-cli. Shouldn't these same checks run on install and confirm/deny that the ancestors provide the proper semver for dependencies their children are asking for?

@EstesE
Copy link

EstesE commented Mar 11, 2015

I had the same issue and the fix for me was updating ember in my package.json:

"ember-cli": "0.2.0"

@jesuskwice
Copy link

Hi all, FWIW, I found the root of my problem was that I tried updating ember-cli directly in package.json and running npm install, as opposed to the proper clean way of doing it described here:
http://www.ember-cli.com/#upgrading

After following the process outlined in the Project Update section, all the unmet dependency issues were resolved. Posting in case it saves anyone else a bit of headache.

@miguelmota
Copy link

Same issue on ember-cli@0.2.0-beta.1

Solution:

rm -rf node_modules bower_components dist tmp
npm install ember-cli@0.2.0 --save-dev
npm install
bower install

@othiym23
Copy link
Contributor

I'm just going to cut and paste the entire commit message for 051c473, which fixes this bug:

The npm@<3 installer uses an elaborate data tree built in-memory as the install process runs to track which dependencies have already been seen in the tree. This allows the installer to determine whether a parent dependency satisfies the current semver requirement.

However, if one version of a dependency is specified at one level of the tree, and then a child of that level includes that same dependency bundled at a different version, and one of that dependency's children depends on this same dependency at yet another version, it will end up matching against the version above the bundled dependency. This can lead anyone trying to figure out what's going on into a phantasmagorical wonderland where nothing is real, and can also produce an inconsistent installed tree.

The solution is to ensure that the bundled dependency versions are added to the tree, but in order to do this, we need to know exactly which version got bundled. This requires a call to readInstalled, because the version that was bundled isn't included anywhere in the package metadata. Since readInstalled is slow, installMany will only call it if it knows there are bundledDependencies for the current package.

@udfalkso
Copy link

udfalkso commented May 2, 2015

Thanks @mkwallace I'm downgrading to test an old version of my app and your suggestion helped me out.

@maxkwallace
Copy link

@udfalkso I'm glad it was helpful!

@topherbullock
Copy link

@othiym23 Awesome! 👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants