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.

Sign up for GitHub

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

Jump to bottom

Stop package.json type field from influencing corepack binaries #1271

Merged
merged 4 commits into from
Jun 7, 2024
Merged

Stop package.json type field from influencing corepack binaries #1271

merged 4 commits into from
Jun 7, 2024

Conversation

colincasey
Copy link
Contributor

This is a small workaround for a side-effect caused by storing corepack installed binaries within the application folder where the type field from the application's package.json file can affect which module system those binaries are loaded with.

This change adds a dummy package.json file to the folder that the corepack binaries are installed into which should prevent the following from happening:

  • Node.js will treat the following as ES modules when passed to node as the initial input, or when referenced by import statements or import() expressions
    • Files with a .js extension when the nearest parent package.json file contains a top-level "type" field with a value of "module".
  • Node.js will treat the following as CommonJS when passed to node as the initial input, or when referenced by import statements or import() expressions
    • Files with a .js extension when the nearest parent package.json file contains a top-level field "type" with a value of "commonjs".

Instead, because the dummy package.json does not declare a type field, the following rule should apply:

  • Node.js defaults to one module system or the other based on the value of the --experimental-default-type flag
    • Files ending in .js or with no extension, if the nearest parent package.json field lacks a "type" field; unless the folder is inside a node_modules folder.

See https://nodejs.org/api/packages.html#determining-module-system

@fixes #1270

@colincasey
Stop package.json type field from influencing corepack binaries
dc34508 
This is a small workaround for a side-effect caused by storing corepack installed binaries within the application folder where the `type` field from the application's `package.json` file can affect which module system those binaries are loaded with.

This change adds a dummy `package.json` file to the folder that the corepack binaries are installed into which should prevent the following from happening:

- Node.js will treat the following as ES modules when passed to node as the initial input, or when referenced by import statements or import() expressions
  - Files with a .js extension when the nearest parent package.json file contains a top-level "type" field with a value of "module".
- Node.js will treat the following as CommonJS when passed to node as the initial input, or when referenced by import statements or import() expressions
  - Files with a .js extension when the nearest parent package.json file contains a top-level field "type" with a value of "commonjs".

 Instead, because the dummy `package.json` does not declare a `type` field, the following rule should apply:
 - Node.js defaults to one module system or the other based on the value of the ``--experimental-default-type` flag
   - Files ending in .js or with no extension, if the nearest parent package.json field lacks a "type" field; unless the folder is inside a node_modules folder.

See https://nodejs.org/api/packages.html#determining-module-system.

@fixes #1270
@colincasey colincasey self-assigned this Jun 6, 2024
@colincasey colincasey requested a review from a team as a code owner June 6, 2024 18:56
@colincasey
Stop package.json type field from influencing corepack binaries
bcffe49 
This is a small workaround for a side-effect caused by storing corepack installed binaries within the application folder where the `type` field from the application's `package.json` file can affect which module system those binaries are loaded with.

This change adds a dummy `package.json` file to the folder that the corepack binaries are installed into which should prevent the following from happening:

- Node.js will treat the following as ES modules when passed to node as the initial input, or when referenced by import statements or import() expressions
  - Files with a .js extension when the nearest parent package.json file contains a top-level "type" field with a value of "module".
- Node.js will treat the following as CommonJS when passed to node as the initial input, or when referenced by import statements or import() expressions
  - Files with a .js extension when the nearest parent package.json file contains a top-level field "type" with a value of "commonjs".

 Instead, because the dummy `package.json` does not declare a `type` field, the following rule should apply:
 - Node.js defaults to one module system or the other based on the value of the ``--experimental-default-type` flag
   - Files ending in .js or with no extension, if the nearest parent package.json field lacks a "type" field; unless the folder is inside a node_modules folder.

See https://nodejs.org/api/packages.html#determining-module-system.

@fixes #1270
@colincasey
Stop package.json type field from influencing corepack binaries
eac4aea 
This is a small workaround for a side-effect caused by storing corepack installed binaries within the application folder where the `type` field from the application's `package.json` file can affect which module system those binaries are loaded with.

This change adds a dummy `package.json` file to the folder that the corepack binaries are installed into which should prevent the following from happening:

- Node.js will treat the following as ES modules when passed to node as the initial input, or when referenced by import statements or import() expressions
  - Files with a .js extension when the nearest parent package.json file contains a top-level "type" field with a value of "module".
- Node.js will treat the following as CommonJS when passed to node as the initial input, or when referenced by import statements or import() expressions
  - Files with a .js extension when the nearest parent package.json file contains a top-level field "type" with a value of "commonjs".

 Instead, because the dummy `package.json` does not declare a `type` field, the following rule should apply:
 - Node.js defaults to one module system or the other based on the value of the ``--experimental-default-type` flag
   - Files ending in .js or with no extension, if the nearest parent package.json field lacks a "type" field; unless the folder is inside a node_modules folder.

See https://nodejs.org/api/packages.html#determining-module-system.

@fixes #1270
@colincasey
Stop package.json type field from influencing corepack binaries
397249a 
This is a small workaround for a side-effect caused by storing corepack installed binaries within the application folder where the `type` field from the application's `package.json` file can affect which module system those binaries are loaded with.

This change adds a dummy `package.json` file to the folder that the corepack binaries are installed into which should prevent the following from happening:

- Node.js will treat the following as ES modules when passed to node as the initial input, or when referenced by import statements or import() expressions
  - Files with a .js extension when the nearest parent package.json file contains a top-level "type" field with a value of "module".
- Node.js will treat the following as CommonJS when passed to node as the initial input, or when referenced by import statements or import() expressions
  - Files with a .js extension when the nearest parent package.json file contains a top-level field "type" with a value of "commonjs".

 Instead, because the dummy `package.json` does not declare a `type` field, the following rule should apply:
 - Node.js defaults to one module system or the other based on the value of the ``--experimental-default-type` flag
   - Files ending in .js or with no extension, if the nearest parent package.json field lacks a "type" field; unless the folder is inside a node_modules folder.

See https://nodejs.org/api/packages.html#determining-module-system.

@fixes #1270
@colincasey colincasey enabled auto-merge (squash) June 7, 2024 12:46
@colincasey colincasey merged commit 1c0e88a into main Jun 7, 2024
11 checks passed
@colincasey colincasey deleted the fix_1270 branch June 7, 2024 16:44
@heroku-linguist heroku-linguist bot mentioned this pull request Jun 10, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@joshwlewis joshwlewis joshwlewis approved these changes

Assignees

@colincasey colincasey

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Yarn 4.4.2 installed with corepack fails to run when package.json contains "type": "module"
2 participants
@colincasey @joshwlewis