Webpack CLI - Define features and tasks of the package

[DanielaValero]

We are at the moment setting up most of the groundwork of the project. In order to move forward we need to define the set of features and tasks that the project needs.

In the slack channel we have agreed that we would like to work with a TDD approach. Therefore setting up the TDD would be the first step.

Also, most of the conversation about the features, is being held at the webpack repo in this issue webpack/webpack#3466

So far, the lists of tasks would be:

• Setup contributing guidelines: This includes also defining the workflow of the project. Status: done, see Feature/setup commits validation and contributors readme #3
• Set TDD tooling. Status: On Going, See Jest and Inquirer Integration [WIP] #5
• Set a project with the 'user stories' of the features the project will have

[hulkish]

Definitely some things I think where this could be super useful.:

1. Lightweight / Shallow scaffolding (similar to npm init/git init):

~/my/project$ webpack-cli init

This utility will walk you through creating a webpack.config.js file.
It only covers the most common items, and tries to guess sensible defaults.

Press ^C at any time to quit.
target runtime: <node|browser>
entry file: (app/index.js)
output directory: (dist)
module rules: 
  Idea: maybe implement a full on 
  wizard-like workflow? (potential rabbit hole!)
  1. test patterns: /\.jsx?/
    uses: babel-loader (maybe make suggestions here?)
  2. test patterns (..etc)
do you want to generate a setup file for test runners? (require.context etc)

2. Shorthand help shortcuts to specific configuration docs:

~/my/project$ webpack-cli docs <config property>

• Example values:

  • resolve:modules
  • module:rules
  • output

• Example usage:

~/my/project$ webpack-cli docs output

The top-level output key contains set of options instructing 
webpack on how and where it should output your bundles, 
assets and anything else you bundle or load with webpack

  - chunkFilename                           <shorthand desc>
  - crossOriginLoading                      <shorthand desc>
  - devtoolFallbackModuleFilenameTemplate   <shorthand desc>
  - devtoolLineToLine                       <shorthand desc>
  - devtoolModuleFilenameTemplate           <shorthand desc>
  - filename                                <shorthand desc>
  - hotUpdateChunkFilename                  <shorthand desc>
  - hotUpdateFunction                       <shorthand desc>
  - hotUpdateMainFilename                   <shorthand desc>
  - jsonpFunction                           <shorthand desc>
  - library                                 <shorthand desc>
  - libraryTarget                           <shorthand desc>
  - path                                    <shorthand desc>
  - pathinfo                                <shorthand desc>
  - publicPath                              <shorthand desc>
  - sourceMapFilename                       <shorthand desc>
  - sourcePrefix                            <shorthand desc>
  - umdNamedDefine                          <shorthand desc>

...I have a lot more I'm kind of excited to add to this list lol.. but these are first that come to mind.

[evenstensberg]

• https://www.npmjs.com/package/inquirer-test
• https://github.com/facebook/jest/blob/master/examples/manual_mocks/__tests__/FileSummarizer-test.js
• https://dmitriiabramov.github.io/jest-cheatsheet/index.html
• https://github.com/SBoudrias/Inquirer.js/tree/master/test
• https://glebbahmutov.com/blog/unit-testing-cli-programs/
• https://github.com/caitp/node-mock-stdin

[DanielaValero]

Here a sumarized list of the on going discussion about the features of this package.

Goal of webpack-cli

Be a command line tool to help developers to configure and understand webpack. It would be a joint action of the webpack team to achieve the main goal of helping devs not only to understand webpack, but also to use it without troubles.

• Be a tool to bootstrap configurations of webpack
• Validate current configurations ?
• Link to documentation ?

List of suggested features

• Transform a webpack configuration v.1.x to v.2.x
• Create boilerplate setup with customizable implementation
• Add loaders and similar "high-level" features such as entry points / loaders - test loaders configuration (i.e. from an entry point, list files being tested by loader X)
• init - create an empty configuration (similar to npm init or git init)
• setups - create predefined configurations and some files (similar to Yeoman)
• validator - use the built in validation
• hints - recommend non-used features/plugins

More detailed description of the suggested features

Original comment here: webpack/webpack#3466 (comment)

init

A way to build a basic webpack configuration. Exactly like webpack-init. We need to cover the following.

• 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.

add <setup-name>

Adds prewritten config setup to add new loaders, plugins

generate <plugin|loader|setup> <options>

Like ember generate where it can add scaffold for the user to fill up functionality.

<multiple config options> --save <config-name>

Save the working config options to the existing webpack config file or create a new config file. Need also an override to rewrite configs.

validate <config-name>

Validate existing configuration using webpack's schema validator, give meaningful error messages. Nice to have would be to give helpful improvement hints.

help <option>

Kickass help with elaborate examples.

List of similar initiatives

webpack/webpack#3466 (comment)

Example commands

$ webpack init --basic | --code-split | --loader=<loader>

List of open questions

webpack/webpack#3466 (comment)

@ev1stensberg @pksjce @TheLarkInn @michael-ciniawsky @sokra @carlos- Am I missing something?

I'd say that from this list, we should prioritize the features that we find more relevant to ease the setup process. However, having a clear list of features is also very relevant.

Also, something that we would need also to document and define clearly, is what will be the difference between the webpack cli, and webpack-cli. We might get it, because we are involved in this discussions, but devs using the package will probably get confused.

[evenstensberg]

For the init solution we can prompt this from Mink. Install it, use npm link and run mink -u or other flags to see example output and interface.

[CrlsMrls]

@DanielaValero, the list lgtm. I would prioritize them as you suggested.

I understand webpack and webpack-cli are in different repositories / npm packages. But in your example command webpack-cli is executed as webpack --init. How can this be? will webpack package require webpack-cli? or is it a typo?

I agree documentation will be also very important, so people do not get confused.

[evenstensberg]

@carlos- It's going to be webpack <options> , executing with webpack-cli is just development.

[hulkish]

@ev1stensberg tbh, I think mink kind of takes it a little further than what makes sense for webpack-cli, specifically the parts where it involves exterior library support as part of the generator routine (react-redux, for ex).

I think there's value in keeping the idea of webpack-cli init just a simple straight forward config initializer.

[evenstensberg]

@hulkish Oh, yeah that's going to be included, but old naming is preserved. We're adding init and migrate. If you run webpack --init react you should get a webpack config with react support!

[evenstensberg]

What I meant with Mink is that we could reuse some of the interface implementation. It's too broad trying to support all libraries in 1 project, that's why it's best to have an implementation similar to yeoman, but we can look at Mink for implementation insight.

[hulkish]

@ev1stensberg agreed, I think maybe allowing for an options like --post-processor react-webpack-config-post-processor (for example) would be great.

[evenstensberg]

We've discussed inline options, could be better to have that as a question in inquirer instead. Else, there should/is going to be an opportunity to create an own package where you'd get that added.

[hulkish]

I don't really know where I can fit in on this... but I'd love to help - point me in the direciton! @ev1stensberg @DanielaValero

[evenstensberg]

Send a message to @pksjce , maybe she has some acorn stuff she needs help with!

[DanielaValero]

Hello @hulkish

We are at the moment setting some ground work, and organizing the features, roadmap, etc. Once we've nailed it, and have the groundwork in place, there will be more clear tasks that you or anyone can pick up to help out.

Greetings

[DanielaValero]

Will close now as we have already a github issue per feature. We will add in the first stage apart from the options to the compiler, an init and a migrate tasks.

All the rest: add <setup-name>, generate <plugin|loader|setup> <options> and help <option>, will be discussed and added after the first version is in place.

Feel free to reopen in case a prio 1 feature is not listed within our roadmap and/or has its own issue opened in order to be part of the first version