Closed kentcdodds closed 3 years ago
I like this in most cases, but this seems like it would prevent the very best practice of, in your package's entry point, doing import foo from 'path'; module.exports = foo;
so as not to expose consumers to babel's .default
(which they should never see).
Sure, doesn't have to be enabled by default :+1:
Right, but it means I wouldn't be able to enable it at all in anything that wasn't a top-level app.
What if it: a) automatically allowed it in a file that was the "main" or "jsnext:main" (since this plugin supports it) in your package.json, and b) allowed an "entrypoints" or "exceptions" config array that allowed it in any file/glob pattern matched?
That way by default it allows your entry point to do the right thing (so I can both use and recommend it) and it's configurable if you have multiple entry points.
Sounds solid :+1:
@kentcdodds which issue with webpack 2 tree shaking are you referring to? I'd like to add a blurb about it in the docs. Also, any other motivating factors for the rule would be welcome.
Whoops! I forgot to link to the issue. It's this one :)
Due to this issue with webpack tree-shaking, and the fact that some people cannot adopt
no-commonjs
quite yet, I think this would be really handy. I've written the rule for my own stuff and would be happy to add it here (or retrofitno-commonjs
with options to cover this use case).Here's my rule:
And the associated tests:
Let me know what you all think :)