Stop using `--no-lockfile` / `--no-shrinkwrap` by default? 🤔

[rwjblue]

I think it is about time that we considered removing the --no-lockfile/--no-shrinkwrap defaults for yarn and npm scenarios.

As of #409, it is possible to avoid if you'd like (that hook allows you to customize the options explicitly, with no default values) but the default of "ignoring lockfile" seems a bit wrong to me nowadays. I'd like to see us be able to have most scenarios use the lockfile and just bump the specific dependencies in the scenario. In my opinion that much more closely resembles what folks will actually do in practice.

For example, I would like to have ember-cli use ember-try scenarios for its floating dependencies test and have that scenario look like:

{
  name: 'floating-dependencies',
  npmOptions: ['--no-lockfile'],
}

Thoughts?

[rwjblue]

Note: this proposal would require adding npmOptions to the list of possible fields in the scenario, so that they can be modified / overriden at each scenario level.

[mansona]

I've just come across this issue and I think I strongly agree with @rwjblue on this 🤔 I'm in the process of trying to remove deprecations from my addons ahead of the 4.0 release and I've been noticing really strange and surprising behaviour when trying to add tests for deprecations.

I think most devs would expect that only the dependency that is specified in the ember-try scenario would change and everything else would remain locked. I know it's very clear in the README but that doesn't mean that it isn't surprising to a lot of people 😂

This is partially responding to #598 (comment)

[ginomiglio]

I agree with this as well.

I also want to point out that given events like veged/coa#99, --no-lockfile is a bit of a security issue too. A compromised package that is quickly discovered by the maintainer has a low risk of making it into most people's builds, but ignoring the lockfile makes it more likely that the bad version is downloaded and run by a CI job before it can be removed.