fix: allow unknown files to use default require as fallback

[anshumanv]

What kind of change does this PR introduce?
fix

Did you add tests for your changes?
Yes

If relevant, did you update the documentation?
No need

Summary

• Remove unnecessary filtering
• We filter all the config based on the available extensions in interpret which is not right and files should fallback to the default node require when they don't have a module needed.

Does this PR introduce a breaking change?
No

Other information
Question -> when we pass some file which doesn't exist ex -c webpack.testconfig.js we fallback to default config webpack.config.js, should we allow that considering the user already passed a config they want to use or should we throw err that config not found?

[evenstensberg]

I don|t think this is correct. We need interpret to take both cjs and regular files. This takes a file and its extention, the double filtering is to check for cjs ext

[evenstensberg]

Considering a file is a small set, I think this is ok

[anshumanv]

This is how gulp also uses it, prepares env which need specific module, rest fallback to the default node loader, no use of filtering

[evenstensberg]

I think this removes cjs support, could you make a test file first?

[anshumanv]

I think this removes cjs support, could you make a test file first?

Nope doesn't remove, I already added tests for cjs when I added it's support #1727

[webpack-bot]

@anshumanv Thanks for your update.

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

@evenstensberg Please review the new changes.

[alexander-akait]

Question -> when we pass some file which doesn't exist ex -c webpack.testconfig.js we fallback to default config webpack.config.js, should we allow that considering the user already passed a config they want to use or should we throw err that config not found?

I think without extensions we should confider it as a JS file, it is edge case, but it doesn't mean we should ignore it

[anshumanv]

I think without extensions we should confider it as a JS file, it is edge case, but it doesn't mean we should ignore it

@evilebottnawi talking about config file that doesn't exist eg webpack.doesntexist.js, should we throw error or fallback to default config?

[alexander-akait]

@anshumanv if config doesn't exists we should throw an error

[anshumanv]

@anshumanv if config doesn't exists we should throw an error

Gotcha, will implement in near future

[anshumanv]

I think we're good here then

[alexander-akait]

/cc @webpack/cli-team