Generate package.json

[wmertens]

Problem set:

• npm does not allow modifying parent dependencies from installed dependencies. This is useful when
  • the app needs to directly require deps, like when setting up eslint or babel. E.g. XO tries to wrap eslint but you still need to install eslint yourself if you add plugins.
  • a peer dep is shared across the app, like React
  • modules are optional, like spdy or session storage plugins, and would otherwise have to always be installed or provided by the app
• You can't add comments to package.json, so you don't know why a certain dep was added

Solution:

It seems to me that these issues can be fixed by generating the package.json from config. Confippet is well-placed for this IMHO; packages could be put into the configuration, maybe with some logic injection.

When combining the configuration, the final set of required packages and settings is known and automatically compared to package.json. If the package.json differs, a warning is printed asking to regenerate it, or to incorporate the new versions into the app config (it could list where what version should go, like app config says [email protected] but package.json has @15.3).

TL;DR: This would allow e.g. configuring webpack SASS support and automatically installing sass-loader.

(At the beginning of the package.json there could be an attribute "__autogenerated": "This file was autogenerated by confippet. Do not edit.")

[jchip]

Hi, thanks for the idea. I am not sure how the problem and solution fit in electrode-confippet. Do you have an example of how this would be used? I think the solution is something that's external that uses confippet as a tool to generate package.json from some other config files? For example, yeoman has support for a package.json template that in turn gets generated into the real package.json.

[wmertens]

Well, electrode-confippet is the single source of truth for the configuration of behavior of the application as well as its build process. What I propose is that it also serves as the npm configuration. Babel, eslint, xo, webpack etc are all implementation details of the archetypes, but due to how npm works, they need to be included as top-level dependencies with top-level files.

Taking it one little step further, since the contents of not only package.json, but also .babelrc, .eslintrc and others (gitignore?, the gulp config?) are all derivable from the configuration (e.g., enabling ava might enable the ava eslint plugin), I propose that that is exactly what should happen. Perhaps it can be done in a separate archetype or something, but it is important that it happens whenever the full app configuration is calculated, because these top-level files all take effect immediately.

Essentially, the zero-configuration-needed approach of create-react-app (through one-size-fits-all) can be achieved with the full configurability of Electrode. The developer makes a declarative configuration change, and that results in the correct configuration being written to the top-level files. When Electrode components are updated, they can result in new top-level files, without the dev needing in-depth knowledge about the domain.

So the Electrode ecosystem could convert the desire for e.g. "I want an ES2017-coded app with live-updating graphql queries and hot-reloading client and server code" and convert that into the correct .babelrc, .eslintrc, npm dependencies, and webpack configuration. All the dev would need to do is write the graphql connections to the database and the frontend code.

Properly configuring transpiling is a moving target. The way to make optimal builds for the current node or browser is not super-simple, but Electrode archetypes could encapsulate this. The resulting .babelrc would be what a generator produces, so it can be inspected to know what happens, but it is automatically updated (or the user is prompted to run something like gulp fixup .babelrc). If at some point another tool is better for transpiling, that can be done with minimal user changes.

Another advantage of this setup is that normally, whenever you add some dependency to your app, it ends up in the package.json without comments. By putting the npm dependencies in the Electrode config, you know where each dependency comes from.