-
Notifications
You must be signed in to change notification settings - Fork 170
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
feat: when strict checking is off, treat like transparent #197
feat: when strict checking is off, treat like transparent #197
Conversation
c3b73f7
to
7c53577
Compare
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.
Would it make sense to add another value to COREPACK_ENABLE_STRICT
to keep a way to disable package.json
parsing? Maybe COREPACK_ENABLE_STRICT=2
or something? It doesn't have to block this, as it seems the implementation covers the more frequent use case, but I feel like Corepack should give a way to skip all interactions with package.json
.
Yeah I think that can be brought up in a separate issue. Although on this matter, my view is that, that behavior removes Corepack's main feature of choosing project-defined package manager, and that makes Corepack yet another npm/yarn/pnpm version manager 😅 |
7c53577
to
bc08ee3
Compare
I can see it being useful as a debug feature, not for production – while I could see why the behavior implemented in this PR would be useful in production, it's two different use cases IMHO. |
I see. Though I feel it would be better as a separate flag, like |
I tend to agree, if the feature was still there it'd make more sense as a separate flag imo ( |
Fixes #195
Relevant to #167 and #157
Edit: final changes:
COREPACK_ENABLE_STRICT=0
now will run as if it is "transparent", that is:packageManager
field.COREPACK_ENABLE_STRICT=0
toCOREPACK_ENABLE_PROJECT_SPEC=0