-
-
Notifications
You must be signed in to change notification settings - Fork 58
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
Document pnpm options and behavior #957
Conversation
Codecov Report
@@ Coverage Diff @@
## master #957 +/- ##
=======================================
Coverage 94.54% 94.54%
=======================================
Files 17 17
Lines 550 550
=======================================
Hits 520 520
Misses 30 30 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
@@ -120,6 +120,11 @@ module.exports = async function() { | |||
dependencies will be restored to their prior state. | |||
*/ | |||
useYarn: true, | |||
/* | |||
If set to true, all npm scenarios will use `pnpm` for install with the `--frozen-lockfile=false` option. At cleanup, your |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is --frozen-lockfile
the same as ignoring the lockfile?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not quite, but it'll allow things to float a bit and update the lockfile if package.json's change.
https://pnpm.io/cli/install#--frozen-lockfile
There isn't exactly a --no-lockfile
option, like what yarn has, though there is a --fix-lockfile
option: https://pnpm.io/cli/install#--fix-lockfile (docs are very light there)
I didn't have any problems with the currently implemented behavior, but something goofy I've noticed with pnpm in general is that when it resolves ^
or ~
ranges, it resolves first to what your have in your "store" (for speed) -- this can be somewhat annoying when I want "latest" -- but also, I heavily rely on automated dependency updating for meaningful dep updates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That may somewhat defeat the point of ember-try; I wonder if ember-try should by default put the specific version in overrides
or resolutions
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I think for consistency, it'd be cool to await latestVersion(dep, { version: range })
on the try-config versions -- because at least then we can assure consistent behavior regardless of package manager. (anyone tried if yarn3/4 does anything goofy? 😅 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could do that today in a try config, but if it isn't set in resolutions or overrides, you'll get whatever the package manager gives you for the version that is set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeep
Thanks! |
RFC: emberjs/rfcs#907
Implementation PR: ember-cli/ember-cli#10287
Advancement PR: emberjs/rfcs#932