| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
we likely should ban known contextual conditions import and require from coming from the CLI |
Sorry, something went wrong.
Co-authored-by: Jordan Harband <ljharb@gmail.com> Co-authored-by: Jan Olaf Krems <jan.krems@gmail.com>
I was thinking about this case and the worst case seems to be having CJS resolve ESM or ESM resolve the CJS path depending on how the ordering works out. Neither of these seem that bad to me though if users want to do it? |
Sorry, something went wrong.
|
@guybedford I agree it isn't fatal in any way if users want to set those for w/e reason, i just have concerns since we have statements in the docs about being exclusive being invalidated. |
Sorry, something went wrong.
|
@bmeck yes worth thinking about, although the main property behind the exclusive definition was that one or the other will always be matched (so there are no fallbacks when both are set in any environment), but that property is retained. |
Sorry, something went wrong.
|
Given that ESM and CJS are ambiguous, it seems like a very not good idea to allow accidental mis-parsing. |
Sorry, something went wrong.
The conditions do not affect the static format of a file and even if you set the require condition and target a .mjs file it is still ESM and fails and vice versa if you set the import condition and target a .cjs file it is still seen as CJS. |
Sorry, something went wrong.
|
@bmeck so to confirm, you're saying even if i have a file that contains nothing but console.log('parsed'), there's no way (as a CJS file extension) it can be parsed as a Module, and no way (as an ESM file extension) it can be parsed as a Script? |
Sorry, something went wrong.
|
@ljharb not via this PR, I might be able to fiddle with the old CJS loader to get it to parse wrong with effort; but to my knowledge it is never possible with the ESM loader. |
Sorry, something went wrong.
I'm pretty sure this should be impossible, at least for accidental cases, since we made require of .mjs throw. It should be likewise for require of .js under "type": "module". I'm sure there are hacky ways to circumvent our check like data URIs or extensionless files or something, but for users who aren't trying to trick Node we should already be erroring. |
Sorry, something went wrong.
Sorry, something went wrong.
PR-URL: #34637 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com> Reviewed-By: Jan Krems <jan.krems@gmail.com>
PR-URL: #34637 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com> Reviewed-By: Jan Krems <jan.krems@gmail.com>
PR-URL: #34637 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com> Reviewed-By: Jan Krems <jan.krems@gmail.com>
Old versions of mocha break after nodejs#34637. This was a bug in mocha, but since this is a widely used module we can expect ecosystem breakage until modules are updated to the latest version of mocha. Drop the conflicting `-u` alias -- we can potentially bring it back once modules have been updated.
Old versions of mocha break after #34637. This was a bug in mocha, but since this is a widely used module we can expect ecosystem breakage until modules are updated to the latest version of mocha. Drop the conflicting `-u` alias -- we can potentially bring it back once modules have been updated. PR-URL: #34935 Refs: mochajs/mocha#4417 Refs: #34637 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Old versions of mocha break after #34637. This was a bug in mocha, but since this is a widely used module we can expect ecosystem breakage until modules are updated to the latest version of mocha. Drop the conflicting `-u` alias -- we can potentially bring it back once modules have been updated. PR-URL: #34935 Refs: mochajs/mocha#4417 Refs: #34637 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com>
|
If this is backported to v12.x, it should come together with #34935 |
Sorry, something went wrong.
|
Thanks, this likely should be backported, if not for any other reason than to simplify the backporting of subsequent modules PRs. |
Sorry, something went wrong.
PR-URL: nodejs#34637 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Geoffrey Booth <webmaster@geoffreybooth.com> Reviewed-By: Jan Krems <jan.krems@gmail.com>
Old versions of mocha break after nodejs#34637. This was a bug in mocha, but since this is a widely used module we can expect ecosystem breakage until modules are updated to the latest version of mocha. Drop the conflicting `-u` alias -- we can potentially bring it back once modules have been updated. PR-URL: nodejs#34935 Refs: mochajs/mocha#4417 Refs: nodejs#34637 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Sorry, something went wrong.
Old versions of mocha break after #34637. This was a bug in mocha, but since this is a widely used module we can expect ecosystem breakage until modules are updated to the latest version of mocha. Drop the conflicting `-u` alias -- we can potentially bring it back once modules have been updated. PR-URL: #34935 Backport-PR-URL: #35385 Refs: mochajs/mocha#4417 Refs: #34637 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Myles Borins <myles.borins@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com>
| Back | FazBrowse Home | New Git URL |
This implements a node --conditions=custom flag for supporting custom resolution conditions in conditional exports, as previously discussed in nodejs/modules#537. A short alias variant, -u=custom is also provided, which stands for "user conditions".
Any custom condition names can be provided as repeated flags, but the core node, default, require and import conditions cannot be changed.
In the process a couple of conditional resolution edge ase bugs are fixed as well here.
@nodejs/modules-active-members
Checklist