webpack/webpack-cli

Feature: Init transformations

pksjce opened this issue · 2 comments

pksjce commented

Do you want to request a feature or report a bug?
Feature - webpack --init should kickstart a volley of inquirer questions. Each of the questions will be backed by a transformer. Each transformer will be transforming a single AST. When the end of questions is reached, the AST will be pretty printed to source code of the webpack config.

What is the current behavior?
Does not exist

If the current behavior is a bug, please provide the steps to reproduce.
Does not exist

What is the expected behavior?

If this is a feature request, what is motivation or use case for changing the behavior?
Initial development

Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.

WIP - project structure for the same.

DanielaValero commented

We should also add here an explicit task to run a validation of the generated config, so we ensure that everything is going to work fine for the user.

Also, would be nice when we could optionally generate webpack 1 and/or webpack 2 configs

Here are also some notes of features the init should have. Taken from #4

  • Add entry point and output path.
  • Add prewritten configs to add babel support, css/scss/less support, hmr and so on.
  • Allow to add DEV and PROD configurations.
  • This should build an annotated webpack configuration file.
  • If a config file is already existing in the given path, the init command should prompt the user if they want to overwrite the current config, or to specify a new filename for the config file.

Also some people have suggested to allow the user to generate a specific config for different architectures, such as vue, or react. When we do so, we should then consider for which frameworks we want to generate a setup, and how they differ from each other. IMHO there are way to many frameworks, and we can't support a generation for them all, at least at the beginning, so, the first question to answer would be:

  • Does it make sense to generate a setup per framework? If so, which ones will we support?
  • How complex do we want to generate the config files? There are multiple ways to write a config file for webpack, we should decide for a configuration file(s) that is simple enough for a developer to understand, that allows to be manually extended, and that also proposes a pattern for a good practice on the setup.

Similar initiatives: webpack-init

evenstensberg commented

I think this is resolved of #105 , reopen if needed.