I'm submitting a bug report!

Webpack version:
1.13.x

Please tell us about your environment:
OSX 10.11.6

Current behavior:
Webpack watcher isn't triggered by files added or removed by git. Scenario:

1. Run webpack --watch within a git directory
2. Add new file, lol.js in directory (webpack discovers it just fine)
3. Run git clean -f (which actually moves lol.js into ./.git/)
4. Observe that webpack doesn't detect the change until any other watched file is saved

NOTE: This is not reproducible when using webpack.OldWatchingPlugin()

Expected/desired behavior:
In the above example, running git clean -f should cause webpack to detect the change, rebundle, and the contents of lol.js shouldn't be present in said bundle.

• Browser: all
• Language: all

Moved from webpack/webpack#2840

Do you want to request a feature or report a bug?

bug

What is the current behavior?

We're performing the actual function call that will throw an error and we simplify the testing of it. You should mock this function instead.

If the current behavior is a bug, please provide the steps to reproduce.
replace expect(object.toString()).toContain('TypeError:') with what is under.

What is the expected behavior?

It should output the exact error message instead of an invalid regexp.

What is the current behavior?

If you run webpack-cli --init webpack-addons-ylvis from the parser branch, it should download and require the package from npm.

If you run the init command with another flag, the parser will run directly after validating packages.

What is the expected behavior?

We should allow the lib/initialize.js module be reusable so we can build up a config with less code.

In order for this to work:

• Make functions more generalistic for our provided options
• initialize.js should be refactored to match the case
• observable-questions needs to be configurable
• lib/parser/ValidateOptions.js needs to be flexible

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

Process-Options is currently making sure webpack gets options applied to the compiler. We're doing some checks here and there before and after the init of the compiler.

We should split or refactor the logic from the options object so that our argv object doesn't serve as a "cleanup" of some flags/options from the CLI.

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

Nein

What is the expected behavior?

N/A

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

This allows us to have a clear project structure, perhaps some perf gains and a moreso maintainable CLI. Doing these changes allows us to find common ground from options and argv instead of treating the argv option partially after we've gotten options built up.

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

Snapple OSX

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 #3
• Set TDD tooling. Status: On Going, See #5
• Set a project with the 'user stories' of the features the project will have

Hi,

I'm doing one of the tutorials that involves using webpack in watch mode, I noticed that whenever my 'root' (or rather current folder) contains '(' or ')' symbols in its paths, watching is not happening.

Am I missing anything? Can I tweak it in some way to get correct watching behaviour?

Moved from webpack/webpack#2258

Do you want to request a feature or report a bug?
This is a requirement for integration testing.

If this is a feature request, what is motivation or use case for changing the behavior?
The idea is that once all the 1->2 migrate transformations are ready, we will do some integration testing on our side by asking the community for some webpack 1 fixture configs.

This isn't really a bug, but more a feature request. I'm not sure if this is the right forum for it?

Please can you add a timestamp to --watch so we can visually inspect if a build took place?

For example, sometimes --watch silently hangs, sometimes I save the wrong file etc. If the code editor and the terminal windows are not always visible at once, being able to glance at the timestamp of the most recent build is useful way to check if things are working.

This is akin to checking the timestamp of an executable to verify that the build succeeded and wrote the file you're expecting it to.

Thank you!

Moved from webpack/webpack#1499

Agenda:

Discuss what to transform and scaffold for all use cases. With other words: discuss what goes to the parser via webpackOptions or to the transform we have. This is so we can better know what to expect from an inquirer prompt, relative to #42

Lets use this ticket to discuss the scope of migrating existing Webpack CLI migration

TODO:

• Agreed upon high level scope points go here

Do you want to request a feature or report a bug?

Feature/Bug

What is the current behavior?

Execution context is bad and reducing performance. We should distance ourselves from the inquirer.prompt context when possible.

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

What is the expected behavior?
throw new WebpackOptionsValidationError(webpackOptionsValidationErrors); should output the error instead of the observable.

1. Discuss how we want to generate needed rules in a webpack-addon package

2. Discuss what to expected returned from an addons package for our transformer to run

3. Discuss on if we should allow .babelrc and such, to also be generated

4. Come up with an example of an webpack-addon

I want to leave my thoughts about webpack's CLI especially.
It's well known that webpack's config can be difficult to master because there are a lot of options and gears. (The most are somehow CLI relevant, but I wrote down everything otherwise I forget it)

1. The current webpack integrated CLI have now an integrated config validator which is worth so much, but because webpack configs are often generated, It were good when you can summarize the effective used configuration in a human readable manner. update: Keep in mind the CLI parameters, too. It's difficult to understand the validate webpack configuration which it will produce.
   A json dump it's not really a solution because the json can be really mess.

2. Some configuration keys in the webpack config are only for CLI. Like devServer, stats etc. This can be really confusing to. Maybe this could be a documentation improvement.

3. There are lot of articles, boilerplates etc. which describe which configuration improvements can used for browser/node - development/production. I really miss that a helper cli which explain your configuration and give tips based on your intents. btw: The webpack doc. should document much more with a practical orientation. "You should use this if... and ... and ... - not use this if...". List advantages and disadvantages (performance/data security affects) too. This whole "cli doctor" could be a part of the CLI too.

4. The native webpack CLI command should really implement a way to output how much time the different loaders/plugins/resolvers have consumed. This is fundamental to understand, especially before you can find bottlenecks and build up a good and fast development environment. This point is more basic than point 3. - this outputs just a performance summary, point 4. analyze your config more deeply - and it must not run the build.

5. Resolver debugging regarding to this: webpack/webpack#3466 (comment)

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

Parser downloads packages one by one, making the CLI slower than expected.

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

Install a package, i.e webpack-cli webpack-addons-ylvis

What is the expected behavior?

The parser runs faster with provided addons

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

Perf

Relative: #60

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

Right not we are testing our tests in many of the test files. This is due that the entire module is circular ( might be hard to isolate the tests ). However we can drag out some of the utility functions from the build instead of mocking those, such as validateAddons.

What is the expected behavior?

Some of the utility functions/isolated modules are not being manually mocked but imported directly.

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

Test improvements

Lets use this ticket to discuss the scope of the migrate command

TODO:

• Agreed upon high level scope points go here

Remember to update our bin files with those from webpack to include the latest fixed from that build. ( At first release/integration to the webpack repo)

Do you want to request a feature or report a bug?
Feature enhancement

What is the current behavior?
Currently we are showing some basic diffs between the original config and the new webpack2 config created for the approval of user.

What is the expected behavior?
We would like to enhance this to state the reason for each of the change. This could guide the user to nuances of the change made and explain concisely what exactly the transformations did.

If this is a feature request, what is motivation or use case for changing the behavior?
This is educational and makes the migration more reasonable

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Subscribe has unexpected side-effects and also it isn't working correctly in the parser module because of that. Errors are not being clear and in general it doesn't work as expected.

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

N/A

What is the expected behavior?

Errors are clear, such as webpackValidationErrors and also other errors.

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

Bugfix

I would like the option to be able to rebuild on save when using watch without webpack looking at the last modified date of files.

I understand rebuild can be resource intensive, but sometimes it is useful to the dev to be able to build as a sanity check or just to refresh the project.

Moved from webpack/webpack#1992

Do you want to request a feature or report a bug?

feature

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

Even after a successful transform there is no way to say that the produced code is a valid JS. We could implement a separate step that will validate the produced code for syntax errors and if there are any, we could throw a more helpful error.

This is easy to achieve using ESLint parser without any rules.

I understand that the -p options has no way of suppressing underlying warnings. That's a pain. I'm seeing hundreds of lines of noise as Uglify generates warnings for every line of every third-party dependency in the project. This makes webpack -p not a good option for me, when otherwise its working well and saving me some work. I hope this gets looked at.

webpack/webpack#2352 (comment)

Do you want to request a feature or report a bug?

Feature

What is the current behavior?
Right now, the parser is pretty slow if run multiple times. We need to skip some steps, such as re-validating each package and then run the prompt. I suggest that we merge the packages first and send it to the parser.

We could also run some functions in parallel?

What is the expected behavior?

Faster prompting

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

v2 🎉

What is the current behavior?
The parser has some lintin errors.

If the current behavior is a bug, please provide the steps to reproduce.
Run npm run lint and see the output.

What is the expected behavior?
There are no lintin errors in the parser.

/Users/dvale2/workspace/open-source/webpack-cli/lib/parser/resolve-packages.js
  18:42  warning  'result' is defined but never used                  no-unused-vars
  19:8   warning  'packageModule' is assigned a value but never used  no-unused-vars
  30:12  warning  'err' is defined but never used                     no-unused-vars

✖ 3 problems (0 errors, 3 warnings)


> [email protected] lint:test /Users/dvale2/workspace/open-source/webpack-cli
> eslint ./tests


/Users/dvale2/workspace/open-source/webpack-cli/tests/__mocks__/parser/resolve.mock.js
  11:21  warning  'pkg' is defined but never used     no-unused-vars
  16:39  warning  'result' is defined but never used  no-unused-vars

Move logic to allow the parser to be reusable.

I'm submitting a feature request

Webpack version:
2.x

Please tell us about your environment:
OSX 10.x

Current behavior:
I'm not sure if this was discussed before, but it's one of the pain point for me in webpack workflow.

When config / config's dep is updated — hot reloadable server (or watch mode) must be restarted manually. Usually this hot reloadable server is not stand-alone process, but part of the bigger task or even lives inside docker container. And in case of config related change — the only way to pick this up is to restart everything.

Expected/desired behavior:

It'd be cool if webpack could track such changes and rebuild everything from scratch w/o killing current process.

What is the motivation / use case for changing the behavior?

It'll make easier:

• work on webpack config setup
• work w/ loader's configs, eg postcss plugin's options (js vars etc)

Moved from webpack/webpack#3153

Agenda

Refactor the parser so we can benefit from it more with classes instead of a lot of smaller modules if needed.

Do you want to request a feature or report a bug?

Feature.

What is the current behavior?

webpack --watch works, but it's not ideal in all cases. Perhaps something else than Chokidar would work better esp. with newly added files. See webpack/webpack#1863 for reference.

What is the expected behavior?

webpack --watch should be more robust (works with more cases).

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

Improved user experience.

TODOS

Migrations

• loaders -> rules
• pre/postLoaders -> rules with enforce: 'pre/post'
• solve for -loaders suffix.
• resolve.root -> resolve.modules
• remove json-loader
• add sourceMap: true to UglifyJsPlugin
• change ExtractTextPlugin syntax
• remove OccurendeOrderPlugin
• add LoaderOptionsPlugin with minimize:true ,context and debug

NFR

• Tests should pass
• Add yarn support
• Add node 4 support

Do you want to request a feature or report a bug?
This is a feature request

What is the current behavior?
There is no automated tool to help migrate from webpack 1 to webpack 2.

If the current behavior is a bug, please provide the steps to reproduce.
NA

What is the expected behavior?
The expected behavior is to have webpack-cli help make this migration automatically.

If this is a feature request, what is motivation or use case for changing the behavior?
It is not clear from first glance as to what it takes to migrate breaking features for webpack2. Providing an automated option would be the best case scenario

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

Node.js version > 0.12.17

I tried out the sweet --migration flag, and it freaking worked!! One thing that was unexpected (until I figured it out), was this diff:

-               loaders: [
-                       {test: /\.json/, loader:'json'}
-               ]
+               rules: []

This is correct but it still caught me off guard so I questioned what I was seeing.

Would be nice for each transformation would make describe what the transform does and why:

-               loaders: [ 
-                       {test: /\.json/, loader:'json'}
-               ]
+               rules: [] //json-loader is now implemented out of the box.

I'm submitting a bug report

Webpack version:
1.13.2

Please tell us about your environment:
Windows 7

Current behavior:

Minimal test case.

Consider the following JS file index.js (the only file in a folder):

var k = 0;

I'm trying to start webpack in watch mode:

webpack index.js bundle.js --watch

When my work folder is c:\dev\, everything works as expected. But if I work in folder c:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs\, webpack doesn't rebuild project after I change index.js file.

Expected/desired behavior:
Watch mode should work in any folder.

Notes
I tried to understand the source of the problem. Looks like npm module is-glob (dependency list: webpack->watchpack->chokidar->is-glob) thinks that c:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs\ is a glob and watchpack tries to listen changes in wrong not existing directory (c:\Program Files x86\Apache Software Foundation\Apache2.2\htdocs\?).

Maybe, it will help you to fix this bug!

Moved from webpack/webpack#2994

General Information:
webpack version: 1.13.2
OS: Windows 10 Anniversary Update and webpack is running in Windows Subsystem for Linux(The new bash on Ubuntu)

I"m trying to run webpack in watch mode by using:

webpack --watch

and by also setting watch mode in config:

context: path.join(__dirname, '/src'),
devtool: debug ? 'inline-sourcemap' : null,
entry: './js-src/scripts.js',
watch: true,
module: {

All webpack does is run the transpiler and exit.
Example of output when running watch mode:

Hash: 045070ba2ed9ce40edf7
Version: webpack 1.13.2
Time: 2146ms
         Asset     Size  Chunks             Chunk Names
scripts.min.js  1.89 MB       0  [emitted]  main
    + 172 hidden modules

I'm not sure what i'm doing incorrect?

Moved from webpack/webpack#2949

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
Currently we have a custom testing workflow where we compare hardcoded output config to the transformed output. This is tedious as we have manually update output conifgs.

What is the expected behavior?
It would much easier and nicer to have verified jest snapshots and not have to hardcode output test config

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
Poorly formatted configs, or new ast nodes that are generated appear inline and hard to read after --migrate.

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

What is the expected behavior?
Be prettier (put intended) than what is output now.

If this is a feature request, what is motivation or use case for changing the behavior?
I was able to add @jlongster's prettier and pass the string in to be formatted:

Below is how I implemented this feature (at a very rough level).

transformations/index.js

  return pretty.format(ast.toSource(recastOptions), {singleQuote: true, tabWidth: 4});

The results were, damn fine looking!

var path = require('path');
var webpack = require('webpack');

// lets take this webpack v1 config and migrate it to v2 !!! <3333

module.exports = {
    debug: true,
    devtool: 'eval',
    entry: ['./src/index'],
    output: {
        path: path.join(__dirname, 'dist'),
        filename: 'index.js'
    },
    plugins: [
        new webpack.OccurenceOrderPlugin(),
        new webpack.optimize.UglifyJsPlugin({
            sourceMap: true
        }),
        new webpack.optimize.LoaderOptionsPlugin({
            debug: true,
            minimize: true
        })
    ],
    resolve: {
        modules: ['foo']
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                use: 'babel-loader',
                include: path.join(__dirname, 'src')
            }
        ]
    }
};

Thoughts @pksjce @ev1stensberg @kenwheeler @okonet? Spoke with folks at prettier and they said if passing a direct string is a concern and overhead we could look into the future passing a direct AST.

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

When we run webpack-cli --init webpack-addons-ylvis we get an validation error. We need to add some transformation rules to transform our answers to a valid webpack configuration before running the validation check.

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

1. Switch to parser branch
2. Clone/Download
3. Run webpack-cli --init webpack-addons-ylvis

What is the expected behavior?

We should get a clean webpack config outputted.

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

V1 release 🎉

Error where this occurs: https://github.com/webpack/webpack-cli/blob/feature/parser/lib/inquirer-prompt.js#L21

Do you want to request a feature or report a bug?

Feature (nitty gritty suggestion, so close it if you don't think it's worth it)

What is the current behavior?
In the test config I'm using to test the webpack-cli's migration I use a relative output path dist. This is not migrated to an absolute path, which is required according to docs (in practice it isn't really required) and is required by webpack-dev-server.

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

Set output: { path: 'dist' }

What is the expected behavior?
webpack 1 config:

output: {
  path: 'dist',
  filename: '[name].js'
}

...becomes webpack 2 config:

output: {
    path: path.join(__dirname, 'dist'),
    filename: '[name].js'
  }

If this is a feature request, what is motivation or use case for changing the behavior?
I'm thinking the migration feature could be a good way to ensure people use an absolute output path, mostly to harmonize how people configure webpack.

• supports this issue: webpack/webpack#3660
• supports how docs describe webpack 2 config (https://webpack.js.org/configuration/output/#output-path) and requirement for webpack-dev-server

Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.
MacOS
node v7.4.0
webpack-cli: https://github.com/webpack/webpack-cli.git#a46edbb10e443a0e256038212d4f44042c8e1dc2

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

Motivation: To have a folder structure that easily shows what the different parts of the project are, and that helps developers to find their way through the code.

Example:

/
|- migrate
|-- ...
|- transformations
|-- loaders
|-- utils
|-- ...
|- init
|-- basicSetup (entry, output, loaders: css, scss, less, etc)
|-- FrameworksSetup
|-- environmentSetup (prod/dev)
|-- ...
|- parser
|- validation
|-- ...
|- schema
|- compiler (functionality of webpack cli)
|-- ...
|- utils
|-- ...

So, basically the idea here is that the folder structure, would be like the tree view of a feature diagram.

I've set up one in the wiki page of the features definition, here the link and diagram:
https://github.com/webpack/webpack-cli/wiki/Features-definition---v1

                                       Webpack-Cli
    Webpack                     +-------------------------------------------------------------------------------------------------+
+------------------------+      |                                                                                                 |
|                        |      |                                                                                                 |
|     +---------+        |      |                                        +---------+            +---------+                       |
|     | Schema  |        |      |         Shared Code->                  |  Parser +--+         |  Utils  +--------------+        |
|     +---------+        +------+                                        +---+-----+  |         +-+------++              |        |
|                        |      |                                            |        |           |      |               |        |
|    +--------------+    |      |                                            |        |           |      |               |        |
|    |  Validation  |    |      |                                            |        +----------------+ |               |        |
|    +--------------+    |      |                                            |                    |    | |               |        |
|                        |      |         Main Features ->                   |     +---------+    |   ++-+--------+   +--+-----+  |
+------------------------+      |                                            +-----+ Migrage +----+   |   Init    |   |Compiler|  |
                                |                                                  +-+-------+        +-+--+------+   +--------+  |
                                |                                                    |                  |  |                      |
                                |                                 +------------------+   +--------------+  |                      |
                                |                                 |                      |                 |                      |
                                | +-------+              +--------+---------+       +----+---+    +--------+-+                    |
                                | | Utils +--------------+  Transformations |       |Inquire |    | Generate |                    |
                                | +-------+              ++---+-------------+       +--------+    +--+-+----++                    |
                                |                         |   |                                      | |    |                     |
                                |                         |   |                                      | |    |                     |
                                |                         |   |                         +------------+ +----+--------------+      |
                                |          +---------+----+---+--+                      | basicSetup | || frameworkSetup   |      |
                                |          | Loaders |   |Plugins|                      +------------+ |-------------------+      |
                                |          +---------+   +-------+                             +----------+                       |
                                |                                                              | envSetup |                       |
                                |                                                              +----------+                       |
                                |                                                                                                 |
                                |                                                                                                 |
                                +-------------------------------------------------------------------------------------------------+

Source of diagram: http://asciiflow.com/#0B0GSsVdGpyRiVFE2c1dqSjZiYUk

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
The cli options from webpack exist in our repo, but have not been yet adapted to our new code design.

What is the expected behavior?

• All the webpack cli options are functional and tested in webpack-cli
• The code is adapted to the webpack-cli code design

If this is a feature request, what is motivation or use case for changing the behavior?
In order to have a unified place where to find all the cli options of webpack, all the webpack cli commands should belong to the webpack-cli repo

Relates to: #25

Currently, webpack --quiet ignores the files passed, while still outputting to the console:

Hash: 6dbc5ab44333d067d673
Version: webpack 1.4.0-beta6
Time: 11ms

It would be nice to have the --quiet option work as expected, i.e. silence all non-error messages.

Moved from webpack/webpack#490

Motivation:
Make a plan to be able to use code from webpack, such as the validation or the schema, and at the same time publish the webpack-cli tonpm so the project can be imported in webpack, so is a built in functionality.

Problem:
When we add webpack in our dependencies, and later on, webpack adds us as a dependency, we would get to the circular dependency problem.

How could we avoid this issue?

Should we have the validation and schema published as a separate package, which can be consumed by webpack and webpack-cli without generating a circular dependency problem?

I would never in my right mind add parenthesis to a path name (i.e. "(" or ")"). Unfortunately Dropbox does this when you have a personal account and company account on the same machine. I store my personal projects in "~/Dropbox (Personal)". I've been trying for a while to figure out why I couldn't get react hot reloading to work and the parenthesis in the project path seem to cause watch to not notice file change. To reproduce run the webpack tutorial from a directory with parenthesis in its name.

Webpack version:
1.13.1

Please tell us about your environment:
OSX 10.11.5

Current behavior:
webpack --watch will not notice changes in files and thus will not recompile or update the UI.

Expected/desired behavior:
Webpack worked just like it does with a path without parenthesis in the name.

• What is the motivation / use case for changing the behavior?
  Dropbox folder naming suckage.

Moved from webpack/webpack#2753

Lets use this ticket to discuss the scope of the init command

TODO:

• Agreed upon high level scope points go here

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

Current behaviour is that the Parser is having an imperative approach to the first --init command.

What is the expected behavior?

The expected behaviour is that we should make lib/parser more functional to be reused together with the inquirer prompt. This allows us to reuse code, save some space and write elegant, performant code without compromising.

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

Improvement / Performance / Readability / Good Manners

Do you want to request a feature or report a bug?

bug

What is the current behavior?

NODE_ENV=development webpack-cli --migrate ./webpack.config.js ./webpack.config.js
/Users/arosenthal/dev/webpack-cli/lib/transformations/loaderOptionsPlugin/loaderOptionsPlugin.js:22
		.filter(path => path.parent.value.key.name === 'plugins')
		                                     ^

TypeError: Cannot read property 'name' of undefined
    at ast.find.filter.path (/Users/arosenthal/dev/webpack-cli/lib/transformations/loaderOptionsPlugin/loaderOptionsPlugin.js:22:40)
    at Array.filter (native)
    at Collection.filter (/Users/arosenthal/dev/webpack-cli/node_modules/jscodeshift/dist/Collection.js:65:46)
    at module.exports (/Users/arosenthal/dev/webpack-cli/lib/transformations/loaderOptionsPlugin/loaderOptionsPlugin.js:22:4)
    at transforms.forEach.f (/Users/arosenthal/dev/webpack-cli/lib/transformations/index.js:40:26)
    at Array.forEach (native)
    at transform (/Users/arosenthal/dev/webpack-cli/lib/transformations/index.js:40:13)
    at module.exports (/Users/arosenthal/dev/webpack-cli/lib/migrate.js:9:23)
    at Object.<anonymous> (/Users/arosenthal/dev/webpack-cli/bin/webpack.js:171:30)
    at Module._compile (module.js:570:32)

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

^^^ do that with this config:

const path = require('path');
const webpack = require('webpack');

module.exports = {
  devtool: '#source-map',

  entry: './src/index.js',

  eslint: {
    configFile: '.eslintrc',
    emitError: true,
    failOnError: true,
    failOnWarning: true,
    formatter: require('eslint-friendly-formatter')
  },

  module: {
    preLoaders: [
      {
        include: [
          path.resolve(__dirname, 'src')
        ],
        loader: 'eslint?',

        test: /\.js$/
      }
    ],

    loaders: [
      {
        loader: 'json',
        test: /\.json$/
      }, {
        include: [
          path.resolve(__dirname, 'src')
        ],
        loader: 'babel',
        test: /\.js$/
      }
    ]
  },

  output: {
    filename: 'rapid7-visualization-color-schema.js',
    library: 'Rapid7VisualizationColorSchema',
    libraryTarget: 'umd',
    path: path.join(__dirname, 'dist'),
    umdNamedDefine: true
  },

  plugins: [
    new webpack.EnvironmentPlugin([
        'NODE_ENV'
    ])
  ],

  resolve: {
    extensions: [
      '',
      '.js'
    ],

    root: __dirname
  }
};

What is the expected behavior?
it transforms the config in to an wp2 compatible one.

Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.
node: v6.9.1
OS: OS X El Capitan 10.11.6

@TheLarkInn asked me to post this as an issue here. Let me know if you need any more info. Thanks!

Do you want to request a feature or report a bug?

Bug

What is the current behavior?
I've declared plugins in a variable to be able to add extra plugins for production build (like UglifyJsPlugin), this results in:

node_modules/.bin/webpack-cli --migrate webpack.config.js
<path>/node_modules/webpack-cli/lib/transformations/loaderOptionsPlugin/loaderOptionsPlugin.js:21
		.filter(path => path.parent.value.key.name === 'plugins')
		                                     ^

TypeError: Cannot read property 'name' of undefined

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

Webpack config:

const webpack = require('webpack');

let plugins = [
  new webpack.DefinePlugin({
    alwaysTrue: true
  })
];

module.exports = {
  entry: {
    'app': './src/index.js'
  },
  output: {
    path: 'dist',
    filename: '[name].js'
  },
  module: {
    loaders: [
      {
        test: /\.js$/,
        exclude: /(node_modules)/,
        loader: 'babel-loader',
        query: {
          presets: ['env']
        }
      },
    ]
  },
  devtool: 'source-map',
  plugins: plugins
};

What is the expected behavior?
Be able to define a separate variable where plugins are specified.

If this is a feature request, what is motivation or use case for changing the behavior?
To have one config for different builds, where extra plugins are added for specific builds, then it's probably a common use case to define plugins in an array.

Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.
MacOS
node v7.4.0
webpack-cli: https://github.com/webpack/webpack-cli.git#a46edbb10e443a0e256038212d4f44042c8e1dc2

Lets use this ticket to discuss:

• Which test lib to use
• Spec naming/location convention

Do you want to request a feature or report a bug?
A bug

What is the current behavior?
When in watch mode, if a file is busy when attempting to emit to it, watch stops functioning. The following error is appropriately logged:

Error: EBUSY: resource busy or locked, open '..\js\bundle.js'
    at Error (native)

If the current behavior is a bug, please provide the steps to reproduce.
run webpack --watch
save a watched file
output to a file which is currently being used by another process

What is the expected behavior?
An error is logged to the console but watch mode continues to function. This is the behavior of Grunt and Gulp watchers.

Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.
A valid reason why a file could be momentarily busy is if it is being synced to a server directory.

--

Here are the details of my setup:

• webpack version: 2.1.0-beta.25
• node version: 6.9.1
• os: windows 10
• browser: chrome 55

--

Moved from webpack/webpack#3523

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
The generated webpack 2 config needs to be validated with the webpack schema.

If this is a feature request, what is motivation or use case for changing the behavior?
This feature needs to be present for basic hygeine

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.

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

An error is thrown because we don't know the structure of options passed by inquirer.

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

What is the expected behavior?

That we won't get an error when running the CLI init command, and that it first tries to create a webpack configuration.

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

v1 🎉