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

feat: add COREPACK_ENABLE_STRICT env variable #167

Merged
merged 1 commit into from
Sep 1, 2022
Merged

Conversation

aduh95
Copy link
Contributor

@aduh95 aduh95 commented Aug 24, 2022

Fixes: #157

Copy link
Member

@styfle styfle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

manager versions that will be required for the projects you'll run, using
`corepack hydrate`).

- `COREPACK_ENABLE_STRICT` can be set to `0` to prevent Corepack from checking

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit weird that the name is COREPACK_ENABLE_STRICT but the default is true. You only use this environment variable when you want to disable strict checking.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It follows the same pattern as COREPACK_ENABLE_NETWORK. Do you have another name suggestion?

Copy link
Member

@styfle styfle Aug 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer env vars and booleans alike to always be named "enable" regardless of default value so you don't have to think about double negatives when disabling the "disable" variable.

This allows you to change the default value in the future without renaming the env var which is really nice if the consumer needs to set the env var and doesn't know the version of corepack that will be used.

TLDR: keep it as _ENABLE_

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Separately tho, it's always weird and confusing when a boolean option has different behavior between "absent" and "false".

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have another naming suggestion given that this follows an existing pattern. I'm not trying to block or delay this with my comment.

@@ -44,6 +44,8 @@ export async function findProjectSpec(initialCwd: string, locator: Locator, {tra
// A locator is a valid descriptor (but not the other way around)
const fallbackLocator = {name: locator.name, range: locator.reference};

if (process.env.COREPACK_ENABLE_STRICT === `0`) return fallbackLocator;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: might not be needed in this PR, but it'd make sense to move the "parsing" logic in a function so we could be sure the same one is used for enableStrict and enableNetwork

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

Successfully merging this pull request may close these issues.

Usage Error: This project is configured to use <pkgmgr>
5 participants