Uh oh!
There was an error while loading. Please reload this page.
[NEXT]: webpack-cli serve refactor draft - #1011
Conversation
| @@ -0,0 +1,93 @@ | |||
| const fs = require('fs'); | |||
There was a problem hiding this comment.
@hiroppy Just easier for me to draft it faster. Can change it later once plan is more solidified.
alexander-akait
left a comment
There was a problem hiding this comment.
Let's discuss before continue work
| throw err; | ||
| }); | ||
| } | ||
| } |
There was a problem hiding this comment.
/cc @Loonride we need discussion about this, keep this stuff here will not allow us to change logic and fix very quickly in the future, we need create api on webpack-dev-server side, maybe idea with new api method is not bad
There was a problem hiding this comment.
@evilebottnawi I agree, I simply copied and pasted it because I knew I would probably be changing it on the webpack-dev-server side. An alternative to a new API method is introducing some minor breaking changes to the listen method, as I started doing here: webpack/webpack-dev-server#2061, so that the listen method works without any additional configuration for the CLI. I think either approach could work.
There was a problem hiding this comment.
@Loonride yes, let's finish this in webpack-dev-server and continue development here 👍
| if (name === 'serve') { | ||
| return pkgLoc ? require(pkgLoc).serve(args) : null; | ||
| } | ||
| // if (name === 'serve') { |
There was a problem hiding this comment.
Instead of uncommenting, just remove it after wip
knagaitsev
commented
Jul 31, 2019
I've made it so that |
knagaitsev
commented
Aug 1, 2019
A few thoughts:
|
| @@ -0,0 +1,23 @@ | |||
| import * as Server from "webpack-dev-server/lib/Server"; | |||
There was a problem hiding this comment.
/cc @evilebottnawi I made some progress here. In here I put basically the ideal version of what we want, so minimal options handling before starting the server.
I think flags.js should live in webpack-dev-server in the future, rather than here, because then we can easily make updates without changing webpack-cli, but we can put that in webpack-dev-servernext later. Do you agree?
Edit: Also, should CLI option tests live in webpack-dev-server, then spawn the webpack-cli serve command?
There was a problem hiding this comment.
The tests for options should live inside webpack-cli - since it owns the corresponding API for said options.
webpack-dev-server should have tests that validates integration & compatibility with webpack-cli api. For ex, this would apply to your changes for webpack-cli/lib/webpack-cli.js where you have added the processArgs fn, etc.
knagaitsev
commented
Aug 8, 2019
/cc @evilebottnawi@hiroppy Thoughts? I know I still may need to make changes here based on dev server changes, but I think that, optimally, there should be very minimal interaction with dev server options as I have done here. Where should tests be? Should tests related to running the basic Where should the list of dev server CLI flags be? I think |
d1e0eb1 to
4682770Compare| multiple: true, | ||
| }, | ||
| ], | ||
| }; |
There was a problem hiding this comment.
/cc @Loonride we should avoid this file
There was a problem hiding this comment.
It will be changed in next version
evenstensberg
left a comment
There was a problem hiding this comment.
Do you mind rebasing such that you only have the changes to the serve command and related?
2633835 to
1544a12Compareknagaitsev
commented
Sep 7, 2019
@evenstensberg I did rebase. But I don't think Files Changed is any different. Did you see a problem with something? |
8e2d3d9 to
c13f05bCompare
@evenstensberg I rebased. I've moved the dev server flags into the Edit: It seems typescript is still complaining about the .js files, but I didn't alter the |
| const isFlagPresent = (args, flag) => args.find(arg => [flag, `--${flag}`].includes(arg)); | ||
| const stripDashedFlags = (args, cmd) => args.slice(2).filter(arg => ~arg.indexOf('--') && arg !== cmd.name && arg !== cmd.alias); | ||
| const isArgCommandName = (arg, cmd) => arg === cmd.name || arg === cmd.alias; | ||
| const stripDashedFlags = (args, cmd) => args.filter(arg => ~arg.indexOf('--') && !isArgCommandName(arg, cmd)); |
There was a problem hiding this comment.
| conststripDashedFlags=(args,cmd)=>args.filter(arg=>~arg.indexOf('--')&&!isArgCommandName(arg,cmd)); | |
| conststripDashedFlags=(args,cmd)=>args.filter(arg=>arg.includes('--')&&!isArgCommandName(arg,cmd)); |
There was a problem hiding this comment.
Actually I think the logic got messed up and I just followed along with it 🙁
It should be !arg.includes('--'), because we want to get rid of all the arguments with -- in this helper, correct?
evenstensberg
commented
Sep 24, 2019
@Loonride that might be something with your tsconfig file, try tweaking around with it and running |
webpack-bot
commented
Sep 25, 2019
@Loonride Please review the following output log for errors: See complete report here. |
evenstensberg
left a comment
There was a problem hiding this comment.
Small comments and then this is ready, thank you so much @Loonride
| /** | ||
| * | ||
| * Converts CLI args to camel case from dash-separated words | ||
| * |
There was a problem hiding this comment.
could you make this filename hyphen based instead?
Uh oh!
There was an error while loading. Please reload this page.
knagaitsev
commented
Sep 26, 2019
I'm still not sure about the failing CI @evenstensberg |
evenstensberg
commented
Sep 26, 2019
Don't worry about it, is my fault, will deal with that |
evenstensberg
left a comment
There was a problem hiding this comment.
lgtm, baller! Thank you so much for the amazing effort you've put into this and the dev-server 💙
alexander-akait
commented
Sep 27, 2019
/cc @evenstensberg please revert, some problem not solved 😞 |
| multiple: true, | ||
| }, | ||
| ], | ||
| }; |
There was a problem hiding this comment.
/cc @Loonride it is very very very bad, next PR will change a lot of options, we don't need this do in webpack-cli
| } | ||
| if (typeof onListening === 'function') { | ||
| onListening(); | ||
| } |
There was a problem hiding this comment.
We should solve this on webpack-dev-server side, not here
There was a problem hiding this comment.
We should solve this on
webpack-dev-serverside, not here
This onListening is different, it is just a callback as one of the function parameters. It can be removed if needed.
| */ | ||
| export default function startDevServer(compiler, options, onListening): void { | ||
| const firstWpOpt = compiler.compilers | ||
| ? compiler.compilers[0].options |
There was a problem hiding this comment.
Why only 0? What about multi-mode compilation
There was a problem hiding this comment.
@evilebottnawi In the past on webpack-dev-server we only looked at the first compiler in a multi-compiler array to see if it has the devServer object. Do you want to change this behavior?
evenstensberg
commented
Sep 27, 2019
@Loonride could you address these in a new PR? |
/cc @evilebottnawi@hiroppy
What kind of change does this PR introduce?
Initial draft for #900
This makes
webpack-cli serveuse the newcommand-line-argsargument parsing system, and it makes this command call thewebpack-dev-serverAPI, rather than the CLI.Did you add tests for your changes?
No
If relevant, did you update the documentation?
No
Summary
The goal of this change is ultimately to make
webpack-cli servework directly with thewebpack-dev-serverAPI. I have placed this API call instartDevServer, with this file mostly copied frombin/webpack-dev-server.js. Ideally, we can minimalize what this helper does.This draft is still very incomplete, what still needs to be done/considered:
webpack-dev-serverflagswebpack-clisystem?falsework as a CLI flag definition, like with yargs where you could do--inline=falsefor boolsReorganization:
webpack-dev-serverrepository, but it is easier to draft them here.Edit:
--colorCLI flag in favor of simply retrieving thecolorsoption from the compiler options.--infoand--quietflags will also be removedDoes this PR introduce a breaking change?
TBD
Other information