Deprecation warning for addons - future big problems?

Ember CLI
1

Since upgrading to 2.18 I am getting this deprecation warning:

DEPRECATION: An addon is trying to access project.nodeModulesPath. This is not a reliable way to discover npm modules. Instead, consider doing: require("resolve").sync(something, { basedir: project.root }). Accessed from: NPMDependencyVersionChecker (/Volumes/Home/Sites/searchapp/node_modules/ember-cli-document-title/node_modules/ember-cli-version-checker/src/npm-dependency-version-checker.js:11:32)

I found this thread about it which recommends doing:

npm ls ember-cli-version-checker

And seeing what has the old dependency. As it turns out, there are alot of addons I have installed that have the dependency:

 ember-cli-document-title@0.3.3
 ember-cookies@0.1.3
 ember-cp-validations@3.5.1
 ember-radio-button@1.2.1
 ember-resize@0.0.17
 ember-screen@0.2.0
 ember-welcome-page@3.1.1

Those are the latest versions of the addons. I started opening issues on each plugin’s github, but they are already opened by others.

Is there anything else I can do to fix the dependency warning?

2

All modules that have this error user ember-cli-babel 5 and just need to upgrade to addon to en newer ember-cli that uses ember-cli-babel 6. So you can try to run ember-cli-update on the modules involved and make PR’s :wink: .

1 Like
3

OK - I’d actually love to know how to do this. Here’s what I tried:

Created a new project…

ember new ember-quickstart
cd ember-quickstart

installed one of the addons that needs updating…

ember i ember-resize

globally installed ember-cli-update…

npm install -g ember-cli-update

went into the addon’s directory…

cd node_modules/ember-resize

ran ember-cli-update…

ember-cli-update

But the output is:

You must start with a clean working directory

If I try running ember-cli-update at the project level, I get:

Tags match, nothing to apply

What am I doing wrong?

4

I don’t think ember-resize has this problem. So lets take ember-screen as example.

  1. Go to https://github.com/mitchlloyd/ember-screen
  2. press fork on github
  3. than git clone https://github.com/yourgithub/ember-screen.git
  4. run git checkout -b newcli from the ember-screen folder
  5. run npm install and bower install
  6. run git status to see if package-lock.json or something else was changed or added
  7. run git add . if you see change
  8. run git commit -m "package-lock.json change or some other comment" if you see change
  9. run ember update
  10. run tests to see if the addon still works
  11. run step 6,7, and 8 again if something is changed.
  12. run git push origin newcli
  13. go to https://github.com/yourgithub/ember-screen and create a pull request
  14. wait patiently

Until you PR is accepted you can change the version in your projects package.json to:

"ember-screen": "yourgithub/ember-screen#newcli",

This way you can work with the updated module util your PR is accepted.

1 Like
5

Thanks so much for taking the time to write out such detailed instructions. I really appreciate it! Learning alot from this.

1 Like
6

Does this mean that we should stop referencing this.nodeModulesPath in our own addons and instead begin employing resolve.sync()?

7

@notmessenger - Yes, exactly.

1 Like
8

Is there any information anywhere discussing the architectural direction/decision for this? I am not criticizing the decision, just looking for information. It is handy having the Ember CLI tool providing this information rather than having to do this lookup ourselves - what is the reason it is going to stop being provided?

9

One more question: are these the values we should use with resolve.sync() or is it specific to ember-cli-version-checker?

10

The change was made in PR 7401. You can read the discussion there, but the tl;dr is that it’s not not correct to assume there is such a thing as single nodeModulesPath. Node’s resolution algorithm lets you have many node_modules directories. ember-cli was being weird by trying to insist on having a single one, and that broke things like yarn workspaces.

How exactly you should use resolve depends on what you’re trying to do. If your addon has a direct dependency on some other package and you want to find it, you can just do a plain require.resolve (as provided by node standard library).

ember-cli-dependency-checker is doing something different, because it’s not looking for it’s own dependencies, it’s looking for its parent’s dependencies, so it needs to resolve them relative to its parent’s directory, not it’s own. That is where the resolve npm package comes in and why it is sometimes needed.

2 Likes
11

I should add: nodeModulesPath was not a public API, which is why changing it didn’t involve an RFC. But even for private APIs, if we know they’re in active use we issue deprecation warnings until the next LTS release, rather than immediately break them.