Change the default value of --experimental-default-config-file

[marco-ippolito]

The current default filename for --experimental-default-config-file is node.config.json.
Some users believe that having an extra config file makes the DX worse than having the configuration in the package.json.
It is already possible to customize the filename with the flag --experimental-config-file.
Refs: nodejs/node#59842
Let's rediscuss at end of September while we wait for votes/comments

@nodejs/collaborators

[ljharb]

Is there a reason not to make the default be "node.config.json, and if not present, fall back to package.json"?

[marco-ippolito]

that could be an option, you can add it to the poll

[ljharb]

done, it reset my vote but it's soon enough that it should be ok

[anonrig]

Secret third option: default to node.config.json and fall back to package.json

This is kind of the worst possible outcome because it is increasing the cost of the startup time with almost no benefit. Are people voting for this option know the impact on the performance and know that it increases the system calls made in every startup?

[marco-ippolito]

It's opt in but yeah that is a valid concern

[GeoffreyBooth]

This is kind of the worst possible outcome because it is increasing the cost of the startup time with almost no benefit. Are people voting for this option know the impact on the performance and know that it increases the system calls made in every startup?

Personally I want to keep the ability to store my Node config in a separate file. That's the pattern I'm familiar with from most tools, some of which offer the option to also put configuration in package.json. Yes this means that Node will make an extra filesystem lookup on startup once this feature becomes enabled by default, but what's the real world cost of that? A millisecond? I doubt that the C++ equivalent of fs.existsSync is a performance impact that anyone would notice, and the ability to load config files by default is compelling enough to me that I think it's worth it. Likewise for automatically loading .env.

Node needs to look for and load package.json files anyway, so another option could be that a key there tells Node to look for an external config file, like "nodeConfig": "./node.config.json" and so the config file lookup only happens when package.json tells Node to go look for it. But again, I doubt that the performance boost is worth the extra steps we would be requiring of the user. If you want to measure it and prove me wrong, please go ahead 😄

[avivkeller]

I'd assume that many organization members don't get notifications for this repo, so maybe share on slack?

[marco-ippolito]

Sure go ahead

[wesleytodd]

If the configuration contains data that they do not wish to publish they can always use the custom file.

I think this is single-handidly enough to keep using node.config.json as default.

I think this is a reasonable concern. As it stands, folks do not realize how much they publish in package.json files, so it is already something very common. Adding this for the small subset of users who would use it for a published library (vs an application) seems like a reasonable trade.

Especially considering most folks are already not careful about what is included are probably already accidentally (or intentionally) shipping the node.config.json file. And it is much worse to ship a new file than to make a package.json slightly larger (I can back this up with data, but don't want to over complicate the discussion unless this point ends up being meaningful for the decision.

cc @anonrig @marco-ippolito (from the original convo in nodejs/node#59842).

[ljharb]

The third option on the poll seems like the best of both worlds - optimizes for the common case, allows for the scale case.

[targos]

The file is not meant to be published and should not end up in node_modules.

[wesleytodd]

The file is not meant to be published and should not end up in node_modules.

Have the various package managers added it to their default ignore list?

[ruyadorno]

I think it's easy to sell the npm team into adding node.config.json to npm's ignore list: https://github.com/npm/npm-packlist/blob/main/lib/index.js

[guybedford]

If already getting alignment with npm on this, could there just be a private package.json properties list?

[styfle]

The way I see it is that package.json already is the configuration file for the node binary.

For example, these properties change the behavior:

• name
• main
• type
• exports
• imports

So adding a couple new properties for nodeOptions and testRunner seems very reasonable for the default behavior.

That said, what is the expectation for packages in node_modules? Will their nodeOptions or testRunner properties be observed? And how about a package.json in a parent directory?

I think the answer is that its only looking at the root package.json, not recursively walking the filesystem and not looking in node_modules for each package. If thats the case then perhaps a separate a config file makes more sense to avoid confusion over the other properties in package.json which do behave recursively.

Its important to think though this behavior because it will answer these two questions:

1. Should this config be published to npm? (No)
2. Should bundlers and other static analysis tools include this config for app deployment? (Yes)

Please correct me if my assumptions are wrong here.

[marco-ippolito]

The configuration of a module inside node_modules is irrelavant for the consumer. It will is ignored.

Should be published to npm?

I'd say no since it's irrelavant for the consumer (but might be help for local debugging?), just like some publish only the minifed code and not the source code.

Bundlers might need to be aware of its existance for local development.

[GeoffreyBooth]

For example, these properties change the behavior:

All of those properties tell consuming applications how to interact with the module. They're metadata for that package. Something like nodeOptions is different: that's telling the developer of that package how to run Node to properly run the package's project.

I'm not opposed to allowing Node config inside package.json, but it shouldn't only be there, because then it becomes a headache for package authors who want to publish their package without including their development Node config. It's easy to exclude the Node config when it's a separate file, but much less so if it's mixed into the package metadata.

[wesleytodd]

That said, what is the expectation for packages in node_modules? Will their nodeOptions or testRunner properties be observed? And how about a package.json in a parent directory?

They would (and should not) ever be respected.

Should this config be published to npm? (No)

then it becomes a headache for package authors who want to publish their package without including their development Node config

Ideally the registry clients can strip that out. They for sure can for the packument data when publishing, but honestly most (all?) of them now are doing pack modifications, so asking them to also remove keys like this seems a reasonable ask imo.

What is the behavior for tools/binaries? Would nodeOptions be potentially relevant for those when published? Or is that explicitly not a goal?

This should not be a goal (and almost cannot due to the problems it would case), but it is something that the current work around for can be quite painful. Currently the best approach for a binary tool to control it's node runtime is via shell wrapper scripts. I do this quite often to suppress warnings and offer debug entry points, but it means adding additional bin's to the package and having to deal with cross platform support issues.

I am perfectly comfortable keeping the status quo on this, but want to call out that if there was a good way to help that use case, it might be nice.

Bundlers might need to be aware of its existance for local development.

What are you thinking about here? Interested in what a bundler running at the project level would need from a dependency (in node_modules)?

[marco-ippolito]

I'm not talking about node_modules, I'm referring to root level.

[styfle]

All of those properties tell consuming applications how to interact with the module. They're metadata for that package. Something like nodeOptions is different: that's telling the developer of that package how to run Node to properly run the package's project.

Not quite all. If you set type: module, this impacts your own application, not just consumers. When you deploy your application (whether to a remote server or distribute a cli to a client), it must include this package.json in addition to any js files or else the program will crash.

One could make the argument that nodeOptions also falls into this category since its needed to run the node binary.

[darcyclarke]

I have a couple clarifying questions,

• is there any intention to eventually look for/load this default config file... by default? or...
• will we always expect to only ever try to load it if either --default-config-file or --config-file=... is passed?

The reason I ask is because if we ever expect node to automatically look for/load a config then we should want to ensure it's maximally beneficial (so I'd choose to vote for package.json). That said, if we aren't going to ever try to load the file be default & it's always opt-in then it probably makes more sense to avoid conflating node options with something as broadly used as package.json.

Side note, node's config file probably shouldn't be JSON either way (not sure if that was previously debated). If the intention is to codify config that can be passed as/defaults flags to the runtime then it should be flat, kvs which map cleanly to CLI options (ie. ini is likely a more appropriate format akin to .env files so as not to let unnecessary nesting - which does not have a CLI option equivalent - creep in). The existing design already shows signs of this mismatch/conflation; ex.

node --import amaro/strip --watch-path=src --watch-preserve-output --test-isolation=process 

// node.config.json
{
  "$schema": "...",
  "nodeOptions": {
    "import": [
      "amaro/strip"
    ],
    "watch-path": "src",
    "watch-preserve-output": true
  },
  "testRunner": {
    "test-isolation": "process"
  }
}

This schema has unnecessary nesting/structure which doesn't map cleanly to cli options & will eat top-level keys for all "subsystems" if we were to merge it into package.json. A better path would be to make a .node file (or whatever bikeshedded name we want) which is intended to be ini format & map directly to any/all runtime cli options; ex.

# .node file
import[]=amaro/strip
watch-path=src
watch-preserve-output=true
test-isolation=process

Again, this more directly reflects the mapping to cli options/config (plus, you also get comments in ini for free - and people like comments - whereas you only get comments in JSON if we support JSON5/JSONC).