webpack / webpack-cli Goto Github PK
View Code? Open in Web Editor NEWWebpack's Command Line Interface
Home Page: https://webpack.js.org/api/cli
License: MIT License
Webpack's Command Line Interface
Home Page: https://webpack.js.org/api/cli
License: MIT License
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.
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 - 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?
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
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
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?
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!
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
Lets use this ticket to discuss the scope of the init
command
TODO:
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
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
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:
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
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.
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 ๐
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
enforce: 'pre/post'
-loaders
suffix.json-loader
sourceMap: true
to UglifyJsPlugin
ExtractTextPlugin
syntaxOccurendeOrderPlugin
LoaderOptionsPlugin
with minimize:true
,context
and debug
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 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
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)
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
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)
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.
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.
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.
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.
Resolver debugging regarding to this: webpack/webpack#3466 (comment)
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.
Moved from webpack/webpack#2753
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?
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 ๐
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
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.
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:
initialize.js
should be refactored to match the caseobservable-questions
needs to be configurablelib/parser/ValidateOptions.js
needs to be flexibleCurrently, 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
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
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});
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.
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:
Moved from webpack/webpack#3153
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?
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
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.
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
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.
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.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:
webpack --watch
within a git directorylol.js
in directory (webpack discovers it just fine)git clean -f
(which actually moves lol.js
into ./.git/
)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.
Moved from webpack/webpack#2840
.babelrc
and such, to also be generatedDo 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.
Lets use this ticket to discuss the scope of the migrate
command
TODO:
Lets use this ticket to discuss:
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
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
Move logic to allow the parser to be reusable.
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.
Lets use this ticket to discuss the scope of migrating existing Webpack CLI migration
TODO:
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?
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:
--
Moved from webpack/webpack#3523
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?
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
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?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.