[FEATURE] configuration standard for all packages

[trusktr]

I'm not sure if this is feasible, or if it belongs in the Node.js repo.

What / Why

There are often cases where certain dependencies require specific build configurations to work properly in an over all environment (for example).

This configuration may be a Babel config, a Webpack config, or something custom just for that package.

As it stands currently, there is no standardized way to configure packages.

Some people use a convention where they place a field in package.json named after the package, and a package can read that. But it doesn't feel standard enough.

When

When a package need custom config for runtime or build time.

Where

How

It is sometimes the case that JavaScript needs build steps for certain cases. This configuration feature would have an optional "build dependencies" option that can be passed to any package (whether they build native modules, or just transpile JavaScript to a lower form).

Depending on configuration, a package may need certain dependencies that otherwise it would not need (f.e. build dependencies).

So the packages system would be smart enough, in that if a user has certain package configuration, it can determine which additional dependencies to install.

Maybe this feature just needs to be expanded from the existing native module system to the overall JavaScript system (in an easy to use way, native modules are tricky).

This could also be very useful for things like optional dependencies. It would be easy, with config, to specify that a library use (for example) three instead of babylonjs. This would cause the appropriate dependency to be installed. It is similar to peer dependencies, but easier, and a given package that depends on optional deps would have standard way to access configuration API reliably to determine whether certain conditions are specified (it is currently tricky, and any cystom traversal of node_modules is non-standard in these cases).

Current Behavior

• n/a

Expected Behavior

• covered above at a high level

As another example, sometimes package consumers need to consume package source instead of the usual compiled output in order to compile the code in different ways (usually for me I run into wanting to do this with Webpack).

In general there are problems with that sort of thing, which NPM so far provides no common way of handling.

Who

package authors and their users

References

• n/a

[trusktr]

This feature would allow package authors, in a standard way, to add features to their packages where they can say "Oh, you want to have the CSS be external instead of built-into the usual package files, no problem, just add such-and-such option in your project config, then this package will automatically disclude any CSS from its output", and then given that standard configuration, the package author can use Webpack, Babel, or whatever tooling desired, to achieve the result.

In this sense, all packages would have some standard way of allowing users to communicate options to them, where the options may dictate alternate sets of dependencies or build steps, regardless of what source files or build tools the package uses.

There would be configuration on the user side, but such options would map to configuration on the package-side that would dictate dependencies (and hence build tools) to run during installation, or similar.

I could see most packages then shipping default source code output, and some users customizing it.

It happens often that the best way to get TypeScript source code to compile, with full features that are otherwise not limited by declaration file emit, is to ship raw TypeScript source code, and transpile it on the consumer side. A configuration convention would greatly help with this.

TypeScript proclaims that consumers should never transpile TypeScript source, but they've dug a hole in which it can be a necessity due to that linked issue. I'm only using it as one example where a configuration standard could be of great use.

[yogesh-aggarwal]

This feature will be amazing because sometimes developers face a lot of difficulties in fixing these kinds of problems.

[darcyclarke]

npm v6 is no longer in active development; We will continue to push security releases to v6 at our team's discretion as-per our Support Policy.

If your bug is reproducible on v7, please re-file this issue using our new issue template.

If your issue was a feature request, please consider opening a new RRFC or RFC. If your issue was a question or other idea that was not CLI-specific, consider opening a discussion on our feedback repo

Closing: This is an automated message.