Skip to content
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

refactor(options): Move options from createConfig to normalizeOptions #2174

Closed

Conversation

knagaitsev
Copy link
Collaborator

  • This is a bugfix
  • This is a feature
  • This is a code refactor
  • This is a test update
  • This is a docs update
  • This is a metadata update

For Bugs and Features; did you add new tests?

Not yet

Motivation / Use-Case

Currently conceptualizing how options handling should be moved into the API. There will be many minor breaking changes, but I think they will all ultimately be for the better.

Breaking Changes

Read the comments in normalizeOptions.

Additional Info

@jsf-clabot
Copy link

jsf-clabot commented Aug 5, 2019

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

@codecov
Copy link

codecov bot commented Aug 5, 2019

Codecov Report

Merging #2174 into next will decrease coverage by 0.34%.
The diff coverage is 89.28%.

Impacted file tree graph

@@            Coverage Diff             @@
##             next    #2174      +/-   ##
==========================================
- Coverage   93.57%   93.23%   -0.35%     
==========================================
  Files          33       33              
  Lines        1245     1256      +11     
  Branches      363      372       +9     
==========================================
+ Hits         1165     1171       +6     
- Misses         71       79       +8     
+ Partials        9        6       -3
Impacted Files Coverage Δ
lib/utils/createConfig.js 96.25% <ø> (-0.22%) ⬇️
client-src/clients/BaseClient.js 69.23% <ø> (ø) ⬆️
client-src/clients/WebsocketClient.js 55.26% <ø> (ø) ⬆️
client-src/default/utils/getCurrentScriptSource.js 100% <ø> (ø) ⬆️
client-src/default/utils/createSocketUrl.js 100% <ø> (ø) ⬆️
client-src/clients/SockJSClient.js 60.52% <ø> (ø) ⬆️
client-src/default/utils/reloadApp.js 100% <ø> (ø) ⬆️
client-src/default/overlay.js 96.82% <100%> (ø) ⬆️
client-src/default/utils/log.js 100% <100%> (ø) ⬆️
lib/utils/runOpen.js 100% <100%> (ø) ⬆️
... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d0893f1...0965fbc. Read the comment docs.

@codecov
Copy link

codecov bot commented Aug 5, 2019

Codecov Report

Merging #2174 into next will increase coverage by 0.14%.
The diff coverage is 96.12%.

Impacted file tree graph

@@            Coverage Diff             @@
##             next    #2174      +/-   ##
==========================================
+ Coverage   93.88%   94.02%   +0.14%     
==========================================
  Files          34       36       +2     
  Lines        1276     1323      +47     
  Branches      363      379      +16     
==========================================
+ Hits         1198     1244      +46     
+ Misses         71       70       -1     
- Partials        7        9       +2     
Impacted Files Coverage Δ
client-src/clients/BaseClient.js 69.23% <ø> (-5.77%) ⬇️
client-src/clients/SockJSClient.js 60.00% <ø> (-1.54%) ⬇️
client-src/clients/WebsocketClient.js 58.97% <ø> (+1.07%) ⬆️
client-src/default/utils/createSocketUrl.js 100.00% <ø> (ø)
client-src/default/utils/getCurrentScriptSource.js 100.00% <ø> (ø)
client-src/default/utils/reloadApp.js 100.00% <ø> (ø)
client-src/default/index.js 91.56% <80.00%> (-0.66%) ⬇️
lib/utils/createConfig.js 98.70% <88.88%> (+2.24%) ⬆️
lib/Server.js 97.19% <95.45%> (-0.13%) ⬇️
lib/utils/startUnixSocket.js 96.55% <96.55%> (ø)
... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7daff1d...69aa911. Read the comment docs.

@knagaitsev knagaitsev force-pushed the migrate-createConfig-normalizeOptions branch from 0965fbc to eaf36fe Compare August 5, 2019 20:54
@knagaitsev
Copy link
Collaborator Author

/cc @evilebottnawi @hiroppy This is ready for review. I've moved many things from createConfig to normalizeOptions. The end goal, in my opinion, is to be able to remove createConfig completely, so that we can just take the parsed CLI args object and pass it straight into the API (as I am doing in webpack/webpack-cli#1011).

@knagaitsev knagaitsev changed the title refactor(options): Moving options from createConfig to normalizeOptions [WIP] refactor(options): Move options from createConfig to normalizeOptions Aug 6, 2019

if (options.open && !options.openPage) {
options.openPage = '';
// eslint-disable-next-line no-undefined
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems unnecessary. Or if we need it, We'll be able move this rule to .eslintrc.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is necessary, but I moved to the top of the createConfig file for convenience in this file. Let's remove the no-undefined requirement in another PR.

});

if (!options.publicPath) {
// eslint-disable-next-line
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was there originally, but I don't know why. eslint is fine without it.

options.inline = true;
}

// ---- The options below were already here, they are not breaking changes ---- //
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is needed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My mistake, these comments were just helping me stay organized while working on this

@@ -210,131 +209,11 @@ describe('createConfig', () => {
expect(config).toMatchSnapshot();
});

it('publicPath option (not specify)', () => {
const config = createConfig(webpackConfig, argv, { port: 8080 });
// removed: publicPath tests
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto


expect(config).toMatchSnapshot();
});
// removed: watchOptions tests
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto


expect(config).toMatchSnapshot();
});
// removed: contentBase tests
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

@knagaitsev knagaitsev added gsoc Google Summer of Code scope: cli labels Aug 13, 2019
@knagaitsev
Copy link
Collaborator Author

/cc @evilebottnawi @hiroppy Can you review this? I've moved most options from createConfig to normalizeOptions, skipping a few that will need some additional changes to be moved.

I've realized that one difficulty with the approach of merging the compiler's options.devServer with CLI options is default values for CLI. This is because you can't tell the difference between a CLI-set default value and a value that the user set explicitly. I'm hoping that maybe I can completely remove default CLI values on the CLI-side (with the exceptions probably just being host and port, as we need those for the listen method) then I can set default values in normalizeOptions if they are not explicitly set by the user.

@hiroppy
Copy link
Member

hiroppy commented Aug 20, 2019

I wanna wait for #2202 because this pr is related is-absolute-url.

@hiroppy
Copy link
Member

hiroppy commented Aug 20, 2019

I'm hoping that maybe I can completely remove default CLI values on the CLI-side

Agree. I hope so.

const isAbsoluteUrl = require('is-absolute-url');
/* eslint-disable
no-undefined
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's avoid this in favor eslint-disable-next-line

if (argv.bonjour) {
options.bonjour = true;
}

if (argv.host && (argv.host !== 'localhost' || !options.host)) {
if (argv.host) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we remove && (argv.host !== 'localhost' || !options.host)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not have to make this change now, but we need to carefully rethink how we handle the options: host, port, and socket, since these are relevant for the listen method.

The logic in && (argv.host !== 'localhost' || !options.host) is made difficult by the fact that localhost is the CLI default, so we can't tell if the user explicitly asked for localhost or if it was set by default:

default: 'localhost',

My proposal is:

Don't set default values for the CLI options host or port. I have done this in webpack-cli serve:
https://github.com/webpack/webpack-cli/blob/44d0fb01f47852b4dfc7423b8e1dfa6c51872e55/packages/serve/flags.js

Have a clear hierarchy for which value gets used. The order of precedence should be:

  1. CLI value
  2. webpackConfig.devServer value
  3. default value

You can see I have implemented this order of precedence in these lines:
https://github.com/webpack/webpack-cli/pull/1011/files#diff-24921f08fe12bbbb2c25f5ed41d757b4R19-R23

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, i think we should keep https://github.com/webpack/webpack-cli/blob/44d0fb01f47852b4dfc7423b8e1dfa6c51872e55/packages/serve/flags.js on our side, because when we want add cli option it is require change something on webpack-cli side, it is not good

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, i think we should keep https://github.com/webpack/webpack-cli/blob/44d0fb01f47852b4dfc7423b8e1dfa6c51872e55/packages/serve/flags.js on our side, because when we want add cli option it is require change something on webpack-cli side, it is not good

I agree, but I don't think we should move it yet because it will be easier to finish implementing webpack-cli serve with the flags at webpack-cli, then we move it just before release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i.e. webpack-cli will work with webpack-dev-server@3?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that webpack-cli serve could just install the latest webpack-dev-server as a dependency (https://github.com/webpack/webpack-cli/pull/1011/files#diff-e630bd2ce7c76bdd3674ca4624f13b7fR18). Is that not what we want? I think it could be difficult to make refactored webpack-cli serve work with webpack-dev-server@3

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Loonride webpack-cli should not have webpack-dev-server in deps, they should use peerDependenciesMeta with optional: true

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some notes

@knagaitsev knagaitsev force-pushed the migrate-createConfig-normalizeOptions branch from 105fdf9 to c674e87 Compare September 11, 2019 01:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gsoc Google Summer of Code pr: next scope: cli
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants