Converge extension priority parity with that of webpack #1080
Conversation
There was a problem hiding this comment.
Travis is failing at the moment.
Also, looking locally I think there is another existing bug, in that the order in source is not preserved, since it's stored in neutrino.options.extensions as a Set():
neutrino/packages/neutrino/Neutrino.js
Line 48 in c11b1c9
packages/neutrino/extensions.js
Outdated
| @@ -4,7 +4,7 @@ module.exports = { | |||
| // Modifying a value here should have an accompanying change there as well. | |||
| // We can't pull in neutrino there as that would potentially give us | |||
| // conflicting versions in node_modules. | |||
| source: ['js', 'jsx', 'vue', 'ts', 'tsx', 'mjs'], | |||
| source: ['wasm', 'mjs', 'jsx', 'vue', 'tsx', 'ts', 'web.jsx', 'web.js', 'js'], | |||
There was a problem hiding this comment.
I don't think we should put the web.js{x} entries here, since they are react-specific (similar to how we don't put the react-native resolve.alias in any other presets.
There was a problem hiding this comment.
Bah the rest of my comment got lost, since I forgot to press update comment before submitting the review. Trying again:
The value for source ends up in neutrino.options.extensions, which is used for neutrino.config.resolve.extensions as expected, but also used by the Mocha preset for the Babel extensions regex, and the Jest preset for moduleFileExtensions. Do the latter two uses support wasm, or does wasm need to just be for neutrino.config.resolve.extensions (ie webpack) only?
(Similar to how json is added for webpack only:
neutrino/packages/web/index.js
Lines 176 to 180 in c11b1c9
There was a problem hiding this comment.
My guess is yes, so that those files can be imported from tests. Correct me if you think this assumption is invalid.
| @@ -93,7 +93,7 @@ module.exports = class Project extends Generator { | |||
| // here should have an accompanying change there as well. We can't pull | |||
| // in neutrino here as that would potentially give us conflicting versions | |||
| // in node_modules. | |||
| const lint = 'eslint --cache --ext js,jsx,vue,ts,tsx,mjs src'; | |||
| const lint = 'eslint --cache --ext wasm,mjs,jsx,vue,tsx,ts,web.jsx,web.js,js src'; | |||
There was a problem hiding this comment.
I believe the .js{x} entries are a superset of .web.js{x}, making the latter redundant for this case specifically?
Also, can ESLint parse .wasm? I thought the files were binary.
There was a problem hiding this comment.
I believe the
.js{x}entries are a superset of.web.js{x}, making the latter redundant for this case specifically?
Good point. This is the primary reason why I had added these entries to the neutrino source extensions array.
Also, can ESLint parse
.wasm? I thought the files were binary.
Oh, my bad. I thought these were JS-superset files.
I'll make these revisions.
|
The problem wasn't that |
| @@ -4,7 +4,7 @@ module.exports = { | |||
| // Modifying a value here should have an accompanying change there as well. | |||
| // We can't pull in neutrino there as that would potentially give us | |||
| // conflicting versions in node_modules. | |||
| source: ['js', 'jsx', 'vue', 'ts', 'tsx', 'mjs'], | |||
| source: ['wasm', 'mjs', 'vue', 'jsx', 'tsx', 'ts', 'js'], | |||
There was a problem hiding this comment.
Should we drop .ts and .tsx for now (here and for the eslint command), given no core Neutrino preset supports TypeScript, and the inclusion of those extensions apparently made things worse in #1044 (or at least caused confusion)?
There was a problem hiding this comment.
We can do this in a follow-up.
Fixes #1067.
This tries to at least get us close to the correct extension priority with what users should expect. It sucks that this list just keeps growing, but at the moment I think doing something different would be much harder than just hardcoding this right now.