Sails references deprecated dependencies

[SonofNun15]

When installing sails via npm, I am warned about several sails dependencies that are now deprecated:

npm WARN deprecated [email protected]: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0.
npm WARN deprecated [email protected]: DEPRECATED. See readme: https://github.com/gruntjs/grunt-lib-contrib
npm WARN deprecated [email protected]: graceful-fs version 3 and before will fail on newer node releases. Please update to graceful-fs@^4.0.0 as soon as possible.
npm WARN deprecated [email protected]: Grunt needs your help! See https://github.com/gruntjs/grunt/issues/1403.
npm WARN deprecated [email protected]: graceful-fs version 3 and before will fail on newer node releases. Please update to graceful-fs@^4.0.0 as soon as possible.
npm WARN deprecated [email protected]: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0.

Would be ideal to upgrade to lodash 4 in particular.

[nilswx]

Seconded. Sails currently seems to be in some stormy weather when it comes to npm version >= 3.0.0 and the outdated dependencies.

[mikermcneil]

Would be ideal to upgrade to lodash 4 in particular.

@SonofNun15 The lodash and async dependencies definitely matter inasmuch as it affects folks using the automatically-provided global. We're looking at a more flexible way to expose that for Sails v1 (i.e. being able to control the version of the auto-exposed global), so if you or @nilswiersema have an idea on how you'd like to see that implemented, please open a proposal PR.

As far as the other dependencies, while I dislike those deprecation warnings as much as anyone else, for the good of the framework, we don't update dependencies of Sails core unless there are security, stability, or major performance issues that affect Sails (a bit more background on that here as well).

tldr; Whether or not one of our NPM dependencies is officially supported by any other individual or company, they are supported by our core team. We are absolutely committed to fixing any issues with documented features of Sails-- whether they happen to result from the particular versions of dependencies we're using or not.

[mikermcneil]

Sails currently seems to be in some stormy weather when it comes to npm version >= 3.0.0 and the outdated dependencies.

@nilswiersema You bring up a good point as far as perception. The culprit is npm deprecate. As you can see from the example in NPM's docs, the intent of npm deprecate is for emergencies: to log warnings about critical patches (i.e. security, stability, performance). But unfortunately the command is all too often used in a different way; i.e. to encourage users of a particular package to update to the latest version; even if that update includes breaking changes. Package maintainers do this because there are lots of benefits: namely fewer new issues about old versions and getting users to adopt new APIs. But this is really annoying for users, because it forces you to stare at a deprecation message about a package that works just fine-- and the only way to make it go away is to make changes to usage (and then manually check it out and/or write more automated tests, crossing one's fingers and hoping no new bugs were introduced). This is an especially heavy burden for dependent NPM packages (like Sails), because these messages are shown to users of that package (even though there's absolutely zero reason to update its dependencies).

I don't really have a good solution for this, perception-wise. It's not the kind of thing we can afford to spend our time focusing on-- there is too much more important work to be done (improving the documentation, enabling lower-level access to the database through Waterline, continuing down the Sails v1 roadmap, etc.) But if anyone has an idea on how we can improve here, given what I explained above, please let me know.

[SonofNun15]

@mikermcneil: Very good response, thanks. I can respect that. The primary concern is that deprecated versions will be less stable and not well supported. But you have adderssed the concerns here with the exception of the perception issue, which is not exactly your problem.

I personally don't intend to use the lodash global, so that won't be an issue, but will have to resort to referencing multiple versions of lodash so that application code can use lodash 4.

Thanks again.

[mikermcneil]

I personally don't intend to use the lodash global, so that won't be an issue, but will have to resort to referencing multiple versions of lodash so that application code can use lodash 4.

@SonofNun15 Hmm, I can definitely look into that-- but first to make sure I'm understanding you right: Do you mean that if in your project you do:

npm install lodash@latest --save --save-exact

Then lodash 4.x functions are not available if e.g. in a controller you do:

var _ = require('lodash');
// ...
// _.forEach(...)
// lodash 4.x available?

[SonofNun15]

I see what you are saying. Because the application references lodash 2.4.1, any code within that application is stuck on the same version. That is definitely unfortunate. I think it would be advantageous to eventually at least move lodash to 4.* since lodash is a front-facing library commonly used. All of the other older deps are backend pieces that sails can pretty much hide anyway.

[mikermcneil]

Because the application references lodash 2.4.1, any code within that application is stuck on the same version

@SonofNun15 Ah, sorry-- what I mean is that this is not how it's supposed to work in NPM-- if it is working that way, something is wrong. In the example code I wrote up above, Lodash 4.x functions should be available. To use Lodash 4.x in your Sails app, just run npm install lodash --save --save-exact. By default, Sails exposes a _ global purely for convenience, but if you do var _ = require('lodash') when you want to use Lodash within your app, then _ will refer to the Lodash version which is a direct dependency of your app.

I totally misunderstood you, apologies for the confusion! (I thought meant that you were experiencing a bug where that wasn't the case, potentially due to some kind of unexpected global leak or install issue that I hadn't seen locally)

To put my mind at ease, I tried this out with:

• Node 4.3.0 (npm v2.14.12)
• Node 0.10.6 (npm v1.2.18)
• Node 5.4.0 (npm 3.6.0)

And fortunately, I was able to verify that this works as expected in every case, so you should be good to go. I'm going to go ahead and assume this is resolved, but if you notice anomalous behavior, please give it a troubleshooting pass with a clean install and if you still see it, open a new issue with specifics + a link back here and I'll dig in deeper. Thanks!

[SonofNun15]

👍

[mikermcneil]

For future reference, you can find more details about this dependencies in Sails core (and other related packages) in #3969 (comment)