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
Feature/find config recursively #693
Conversation
7ec1855
to
e941b49
Compare
@lakatostamas can you also add some negative test-cases to check what happens when it can not find the 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.
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
Thanks for the review! @hemal7735 Sure, I will add negative cases. @evenstensberg I think I've added one test which is testing the implementation: I think this will perform the following checks: 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. |
bin/convert-argv.js
Outdated
return a.concat(i); | ||
}, []); | ||
|
||
for (i = 0; i < defaultConfigFileNames.length; i++) { |
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 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:
- try to find file
webpack.config
in up-fashion. - if found then return, if not go to step#3
- try to find file
webpackfile
in up-fashion. - 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?
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.
top-down priority is the best
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.
@evenstensberg sorry, I did not get you. Can you give any example?
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.
@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
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.
Yeah both files should always have the same priority at each path of directory structure.
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.
I left some questions and thoughts
bin/convert-argv.js
Outdated
for (i = 0; i < defaultConfigFiles.length; i++) { | ||
const webpackConfig = defaultConfigFiles[i].path; | ||
if (fs.existsSync(webpackConfig)) { | ||
const defaultConfigFileNames = ["webpack.config", "webpackfile"] |
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.
This is a good chance to move "webpack.config"
and "webpackfile"
inside two constants
bin/convert-argv.js
Outdated
return a.concat(i); | ||
}, []); | ||
|
||
for (i = 0; i < defaultConfigFileNames.length; i++) { |
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.
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); |
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.
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?
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.
expect(stdout).toEqual(expect.anything());
could be stripped
test/binCases/config-location/find-recursively/packages/foo/find-recursively.test.js
Show resolved
Hide resolved
Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon. |
friendly ping @ematipico @evenstensberg . No rush, but could you please review it again? Thanks! 🙂 |
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.
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()); |
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.
You should use the extractHash
utility.
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.
No, for now hash is already extracted by default. We have to refactor that bit. Will do it with another PR.
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.
@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", |
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.
remove prod, delays test case
"[id].chunk.js", | ||
"--target", | ||
"async-node", | ||
"--mode", |
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.
remove prod
|
||
module.exports = [ | ||
{ | ||
name: "foo", |
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.
this is wrong
@@ -0,0 +1,7 @@ | |||
var path = require("path"); | |||
|
|||
module.exports = [ |
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.
export object instead
"[id].chunk.js", | ||
"--target", | ||
"async-node", | ||
"--mode", |
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.
remove prod
|
||
module.exports = [ | ||
{ | ||
name: "foo", |
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.
invalid
"[id].chunk.js", | ||
"--target", | ||
"async-node", | ||
"--mode", |
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.
remove prod
@@ -0,0 +1,7 @@ | |||
var path = require("path"); | |||
|
|||
module.exports = [ |
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.
At this level, add a webpack.config.js
file as well, it shouldn't break the test if implemented correctly.
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.
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
bin/convert-argv.js
Outdated
}); | ||
break; | ||
} | ||
const webpackConfigFileRegExp = `(webpack.config|webpackfile)(${extensions.join("|")})`; |
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.
configFileRegExp
is sufficient
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.
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
@lakatostamas Thanks for your update. I labeled the Pull Request so reviewers will review it again. @evenstensberg Please review the new changes. |
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 usedcosmiconfig
but I thinkfindup-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