Skip to content
This repository has been archived by the owner on Sep 2, 2023. It is now read-only.

Simple conditions flag #537

Closed
guybedford opened this issue Jul 29, 2020 · 15 comments
Closed

Simple conditions flag #537

guybedford opened this issue Jul 29, 2020 · 15 comments

Comments

@guybedford
Copy link
Contributor

Since the PR for a --dev flag got stalled at nodejs/node#33171 it could still be useful to provide a top-level way to set Node.js conditions like "development" and "production".

The simplest proposal then would just be to have a top-level --conditions flag:

node --conditions=production,custom x.js

as a comma-separated list of conditions to add to the resolution process.

Perhaps if there is time to discuss this today we can get some feedback before any PR work is attempted.

@jkrems
Copy link
Contributor

jkrems commented Jul 29, 2020

I assume the idea would be that they would be similar to "node" and apply to all import and require resolutions?

@bmeck
Copy link
Member

bmeck commented Jul 29, 2020

@jkrems that brings up a good point about prohibiting some values from the CLI

@ljharb
Copy link
Member

ljharb commented Jul 29, 2020

Would these conditions select for CJS, or ESM? Some folks might but CJS in production, and some might put ESM in production; some users may prefer ESM and some may prefer CJS.

@bmeck
Copy link
Member

bmeck commented Jul 29, 2020

@ljharb I'm not sure I understand the question / workflow

@ljharb
Copy link
Member

ljharb commented Jul 29, 2020

So, pre-ESM, the "browser" field was "CJS meant to be bundled for the browser", and "main" was "CJS meant to be required by node".

In conditions, "require" is for "CJS" and "import" is for "ESM". Which module system is "production" for?

@bmeck
Copy link
Member

bmeck commented Jul 29, 2020

ljharb: it isn't for a module system, it is for a differing implementation; e.g. load the module with debugging hooks exposed vs not

@ljharb
Copy link
Member

ljharb commented Jul 29, 2020

@bmeck right, but load the module as ESM, or as CJS?

@bmeck
Copy link
Member

bmeck commented Jul 29, 2020

@ljharb thats unrelated to even require or import, those conditions are just the means by which it was loaded.

@jkrems
Copy link
Contributor

jkrems commented Jul 29, 2020

@ljharb Conditions can (and in this case likely should) be combined. E.g.:

"exports": {
  "import": { "development": "./dev.mjs", "default": "./prod.mjs" },
  "require": { "development": "./dev.cjs", "default": "./prod.cjs" }
}

@ljharb
Copy link
Member

ljharb commented Jul 29, 2020

@jkrems now that makes sense to me. Is there even a use case for using dev/prod on the first level of exports, as opposed to the second as you illustrated?

@guybedford guybedford added the modules-agenda To be discussed in a meeting label Jul 29, 2020
@jkrems
Copy link
Contributor

jkrems commented Jul 29, 2020

Depending on how terse you want to be, it can be handy to use it top-level like this:

"exports": {
  "require": { "development": "./dev.cjs", "default": "./prod.cjs" },
  "development": "./dev.mjs",
  "default": "./prod.mjs"
}

@bmeck
Copy link
Member

bmeck commented Jul 29, 2020

You also might have modules you never want to use in production, so top level would be "development"

@MylesBorins
Copy link
Contributor

This landed on core, closing

@guybedford
Copy link
Contributor Author

This has now landed as node --conditions A --conditions B or node -u A -u B.

@wclr
Copy link

wclr commented Aug 24, 2020

@guybedford is node (if present) condition is still preferred over those user conditions?

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

No branches or pull requests

6 participants