-
-
Notifications
You must be signed in to change notification settings - Fork 628
[NEXT]: webpack-cli serve refactor draft #1011
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
packages/serve/startDevServer.js
Outdated
@@ -0,0 +1,93 @@ | |||
const fs = require('fs'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you use js
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hiroppy Just easier for me to draft it faster. Can change it later once plan is more solidified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's discuss before continue work
packages/serve/startDevServer.js
Outdated
throw err; | ||
}); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Loonride yes, let's finish this in webpack-dev-server
and continue development here 👍
1fbee3c
to
3908bcc
Compare
lib/commands/external.js
Outdated
if (name === 'serve') { | ||
return pkgLoc ? require(pkgLoc).serve(args) : null; | ||
} | ||
// if (name === 'serve') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of uncommenting, just remove it after wip
I've made it so that |
A few thoughts:
|
@@ -0,0 +1,23 @@ | |||
import * as Server from "webpack-dev-server/lib/Server"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/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-server
next
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
/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
4682770
Compare
packages/serve/flags.js
Outdated
multiple: true, | ||
}, | ||
], | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @Loonride we should avoid this file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be changed in next version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mind rebasing such that you only have the changes to the serve
command and related?
2633835
to
1544a12
Compare
@evenstensberg I did rebase. But I don't think Files Changed is any different. Did you see a problem with something? |
8e2d3d9
to
c13f05b
Compare
@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
|
lib/bootstrap.js
Outdated
const { core, commands } = require('./utils/cli-flags'); | ||
const cmdArgs = require('command-line-args'); | ||
|
||
require('./utils/process-log'); | ||
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const stripDashedFlags = (args, cmd) => args.filter(arg => ~arg.indexOf('--') && !isArgCommandName(arg, cmd)); | |
const stripDashedFlags = (args, cmd) => args.filter(arg => arg.includes('--') && !isArgCommandName(arg, cmd)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
@Loonride that might be something with your tsconfig file, try tweaking around with it and running |
@Loonride Please review the following output log for errors:
See complete report here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small comments and then this is ready, thank you so much @Loonride
packages/serve/argsToCamelCase.ts
Outdated
/** | ||
* | ||
* Converts CLI args to camel case from dash-separated words | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you make this filename hyphen based instead?
I'm still not sure about the failing CI @evenstensberg |
Don't worry about it, is my fault, will deal with that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, baller! Thank you so much for the amazing effort you've put into this and the dev-server 💙
/cc @evenstensberg please revert, some problem not solved 😞 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😞
multiple: true, | ||
}, | ||
], | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should solve this on webpack-dev-server
side, not here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should solve this on
webpack-dev-server
side, 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why only 0
? What about multi-mode compilation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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?
@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 serve
use the newcommand-line-args
argument parsing system, and it makes this command call thewebpack-dev-server
API, 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 serve
work directly with thewebpack-dev-server
API. 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-server
flagswebpack-cli
system?false
work as a CLI flag definition, like with yargs where you could do--inline=false
for boolsReorganization:
webpack-dev-server
repository, but it is easier to draft them here.Edit:
--color
CLI flag in favor of simply retrieving thecolors
option from the compiler options.--info
and--quiet
flags will also be removedDoes this PR introduce a breaking change?
TBD
Other information