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

Feature/find config recursively #693

Merged

Conversation

lakatostamas
Copy link
Contributor

@lakatostamas lakatostamas commented Nov 18, 2018

What kind of change does this PR introduce?
Feature.
Did you add tests for your changes?
Yes.
If relevant, did you update the documentation?
Should I open a PR in this repo: https://github.com/webpack/webpack.js.org ?
Summary
Issue: #689
I used a third-party lib to find the config file recursively. This lib exactly does what we need, but if you think we shouldn't use a third-party for this I remove it and implement it by myself. I checked the "old" solution in config-loader and it used cosmiconfig but I think findup-sync is more suitable for us in this repository. (https://github.com/webpack-contrib/config-loader/blob/859799105c17d89a481b3849f75497ed4f656348/lib/load.js#L63)

Does this PR introduce a breaking change?
No (I guess)

Other information
Closes #689

@jsf-clabot
Copy link

jsf-clabot commented Nov 18, 2018

CLA assistant check
All committers have signed the CLA.

@hemal7735
Copy link
Member

@lakatostamas can you also add some negative test-cases to check what happens when it can not find the file?

Copy link
Member

@evenstensberg evenstensberg left a comment

Choose a reason for hiding this comment

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

I think find-up is the correct approach here, but your test case doesn't test the implementation. You'd need to create a 2-3 level deep folder and place the file there

@lakatostamas
Copy link
Contributor Author

Thanks for the review!

@hemal7735 Sure, I will add negative cases.

@evenstensberg I think I've added one test which is testing the implementation:
here is the test file (2 level deep: packages/foo): test/binCases/config-location/find-recursively/packages/foo/find-recursively.test.js
and here is the webpack.config.js: test/binCases/config-location/find-recursively/webpack.config.js

I think this will perform the following checks:
1, test/binCases/config-location/find-recursively/packages/foo/
2, test/binCases/config-location/find-recursively/packages/
3, test/binCases/config-location/find-recursively/ (webpack.config.js found)

Should I modify this test or it's completely irrelevant?

Sorry if I totally missed the point, this is my first contribution to any webpack-related package.

return a.concat(i);
}, []);

for (i = 0; i < defaultConfigFileNames.length; i++) {
Copy link
Member

@hemal7735 hemal7735 Nov 20, 2018

Choose a reason for hiding this comment

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

We will need some logic change here. Let's see both implementations.

existing-implementation: try to find file from ["webpack.config", "webpackfile"] in cwd.

current-modification:

  1. try to find file webpack.config in up-fashion.
  2. if found then return, if not go to step#3
  3. try to find file webpackfile in up-fashion.
  4. if found then return

Do we see the problem here? Even though webpackfile is there one level above, it would not be discovered, but 2 level up webpack.config would be given chance first.

I would want both files to get a fair chance to be discovered. @evenstensberg @ematipico your thoughts on this?

Copy link
Member

Choose a reason for hiding this comment

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

top-down priority is the best

Copy link
Member

@hemal7735 hemal7735 Nov 21, 2018

Choose a reason for hiding this comment

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

@evenstensberg sorry, I did not get you. Can you give any example?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hemal7735 I think you are right. I implemented a solution with (dynamically created) RegExp, but I didn't merge it into this PR. I also added webpackfile related tests. Could you please check it? https://github.com/lakatostamas/webpack-cli/compare/1f2b7e2..727a59a

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah both files should always have the same priority at each path of directory structure.

Copy link
Contributor

@ematipico ematipico left a comment

Choose a reason for hiding this comment

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

I left some questions and thoughts

for (i = 0; i < defaultConfigFiles.length; i++) {
const webpackConfig = defaultConfigFiles[i].path;
if (fs.existsSync(webpackConfig)) {
const defaultConfigFileNames = ["webpack.config", "webpackfile"]
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a good chance to move "webpack.config" and "webpackfile" inside two constants

return a.concat(i);
}, []);

for (i = 0; i < defaultConfigFileNames.length; i++) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah both files should always have the same priority at each path of directory structure.

expect(code).toBe(0);
expect(stdout).toEqual(expect.anything());
expect(stdout).toContain("./src/index.js");
expect(stderr).toHaveLength(0);
Copy link
Contributor

Choose a reason for hiding this comment

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

Apart the ./src/index.js, is there anything else that we should test in the specific (anything() is too generic)? Also, it is worth to have a snapshot test?

Copy link
Member

Choose a reason for hiding this comment

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

expect(stdout).toEqual(expect.anything()); could be stripped

@webpack-bot
Copy link

Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon.

@lakatostamas
Copy link
Contributor Author

friendly ping @ematipico @evenstensberg . No rush, but could you please review it again? Thanks! 🙂

Copy link
Member

@evenstensberg evenstensberg left a comment

Choose a reason for hiding this comment

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

Reviewed, nice job! You will need to fix the broken test cases, they are not passing

"production"
]);
expect(code).toBe(0);
expect(stdout).toEqual(expect.anything());
Copy link
Member

Choose a reason for hiding this comment

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

You should use the extractHash utility.

Copy link
Contributor

Choose a reason for hiding this comment

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

No, for now hash is already extracted by default. We have to refactor that bit. Will do it with another PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@evenstensberg @ematipico So should I use extractHash here? I think I fixed the broken test cases except this one.

"[id].chunk.js",
"--target",
"async-node",
"--mode",
Copy link
Member

Choose a reason for hiding this comment

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

remove prod, delays test case

"[id].chunk.js",
"--target",
"async-node",
"--mode",
Copy link
Member

Choose a reason for hiding this comment

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

remove prod


module.exports = [
{
name: "foo",
Copy link
Member

Choose a reason for hiding this comment

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

this is wrong

@@ -0,0 +1,7 @@
var path = require("path");

module.exports = [
Copy link
Member

Choose a reason for hiding this comment

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

export object instead

"[id].chunk.js",
"--target",
"async-node",
"--mode",
Copy link
Member

Choose a reason for hiding this comment

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

remove prod


module.exports = [
{
name: "foo",
Copy link
Member

Choose a reason for hiding this comment

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

invalid

"[id].chunk.js",
"--target",
"async-node",
"--mode",
Copy link
Member

Choose a reason for hiding this comment

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

remove prod

@@ -0,0 +1,7 @@
var path = require("path");

module.exports = [
Copy link
Member

Choose a reason for hiding this comment

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

At this level, add a webpack.config.js file as well, it shouldn't break the test if implemented correctly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If I add a webpack.config.js in the same level as webpackfile.js it will break the test because if they are on the same level then webpack.config.js will be used. I've added a webpack.config.js two level above: https://github.com/webpack/webpack-cli/pull/693/files#diff-3f5d33891236c7320bd882814444bca0R1

});
break;
}
const webpackConfigFileRegExp = `(webpack.config|webpackfile)(${extensions.join("|")})`;
Copy link
Member

Choose a reason for hiding this comment

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

configFileRegExp is sufficient

Copy link
Member

Choose a reason for hiding this comment

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

add a constant, so we can add more later, const defaultConfigFiles = ["webpack.config", "webpackfile"] and join them in the regexp instead like the last node in the regexp

@webpack-bot
Copy link

@lakatostamas Thanks for your update.

I labeled the Pull Request so reviewers will review it again.

@evenstensberg Please review the new changes.

@evenstensberg evenstensberg merged commit f9bb82d into webpack:master Jan 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants