npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

Grouping custom configuration in package.json?


Currently if you want to specify custom configuration for whatever in your package.json, you just add a new key and start adding your custom stuff to that object there (I’ve seen some packages doing that)

But why can’t we specify something like a “custom” key which then holds all that custom stuff?

Of course we couldn’t just stop supporting custom values in package.json right ahead and probably that’ll never be possible, but at least encouraging people to do that and putting it in the docs would help I guess.

I just don’t really like how user-defined stuff mixes with the specification so easily. Maybe some of you feel just like me?

That already exists:

People just don’t really care and it’s far too breaking to be enforcing this. The impact would be pretty huge, considering how many people put random stuff in their pkgjson.

Would at least warning (toggleable?) about unknown keys on the root level of the package config be a reasonable option for some future version? :thinking:

I can’t really see that being worth it. This is also something that userland tooling can easily accomplish, and I recommend going that route. Possibly as part of your linting/test runs.

I agree with you metaa, i don’t like user-defined stuff either

I would be in favor of what the http headers have been doing. using a X- prefix do separate non-standard fields.

but maybe use camelCase instead since it makes it easier after parsing

so bundlesize would have to define something like

"xBundlesize": [...]