Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop using --no-lockfile / --no-shrinkwrap by default? 🤔 #597

Open
rwjblue opened this issue Nov 2, 2020 · 3 comments
Open

Stop using --no-lockfile / --no-shrinkwrap by default? 🤔 #597

rwjblue opened this issue Nov 2, 2020 · 3 comments
Labels

Comments

@rwjblue
Copy link
Member

rwjblue commented Nov 2, 2020

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
Copy link
Member Author

rwjblue commented Nov 2, 2020

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
Copy link
Member

mansona commented Sep 12, 2021

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
Copy link

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.

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

No branches or pull requests

3 participants