Sails: Mocha's --globals flag conflicts with Sails 1.1

[svmn]

Sails version: 1.1.0
Node version: 8.9.1
NPM version: 6.8.0
DB adapter name: N/A
DB adapter version: N/A
Operating system: Windows

---

Using mocha's --globals flag in mocha.opts file now causes error

userError: As of Sails v1, if `sails.config.globals` is defined, it must either be `false` or a dictionary (plain JavaScript object) or `false`.  But instead, got: 'sails'
> Note: if no globals config is specified, Sails will now assume `false` (no globals).  This is to allow for more intuitive programmatic usage.
For more info, see http://sailsjs.com/config/globals

Maybe there is some configuration to not take command line arguments for config?

[sailsbot]

Hi @svmn! It looks like you missed a step or two when you created your issue. Please edit your comment (use the pencil icon at the top-right corner of the comment box) and fix the following:

• Verify "I am experiencing a concrete technical issue (aka a bug) with Sails (ideas and feature proposals should follow the guide for proposing features and enhancements (http://bit.ly/sails-feature-guide), which involves making a pull request). If you're not 100% certain whether it's a bug or not, that's okay--you may continue. The worst that can happen is that the issue will be closed and we'll point you in the right direction."
• Verify "I am not asking a question about how to use Sails or about whether or not Sails has a certain feature (please refer to the documentation(http://sailsjs.com), or post on http://stackoverflow.com, our Google Group (http://bit.ly/sails-google-group) or our live chat (https://gitter.im/balderdashy/sails)."
• Verify "I have already searched for related issues, and found none open (if you found a related _closed_ issue, please link to it in your post)."
• Verify "My issue title is concise, on-topic and polite ("jst.js being removed from layout.ejs on lift" is good; "templates dont work" or "why is sails dumb" are not so good)."
• Verify "I have tried all the following (if relevant) and my issue remains:"
• Verify "I can provide steps to reproduce this issue that others can follow."

As soon as those items are rectified, post a new comment (e.g. “Ok, fixed!”) below and we'll take a look. Thanks!

*If you feel this message is in error, or you want to debate the merits of my existence (sniffle), please contact [email protected]

[svmn]

Ok, fixed!

[sailsbot]

@svmn Thanks for posting, we'll take a look as soon as possible.

---

For help with questions about Sails, click here. If you’re interested in hiring @sailsbot and her minions in Austin, click here.

[mikermcneil]

Maybe there is some configuration to not take command line arguments for config?

@svmn not currently- sorry for the inconvenience! I totally agree-- and in fact, I'd like to phase out general-purpose command-line-opt-style configuration in general (and just keep support a few special things, like --staging, --prod, --redis, --drop, etc). Doing that would be a breaking change, though, which would mean Sails 2.0.

In the mean time, I'd love to merge a PR that adds a sails.config.enableDeepCommandLineOptions that is true by default, but that, if disabled, replaces this with a shallow merge, rather than a deep merge -- in other words, instead of _.merge(), do _.extend() aka Object.assign(). (Last but not least, remember we'd also need to add the new config to the docs.)