You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When developing and maintaining a package, it is critical to understand what modules are being exported. There are a couple ways to do this. One way is to add a test for the entry point, like for utils. Another, more obvious way is to be explicit about which modules are being exported in the entrypoint. Currently we allow wildcard exports. I am proposing we stop doing this and instead prefer named exports.
No ESLint rule exists per se to forbid wildcard exports, but evidently you can use no-restricted-syntax as a workaround as described here: import-js/eslint-plugin-import#2493 (comment)
The text was updated successfully, but these errors were encountered:
When developing and maintaining a package, it is critical to understand what modules are being exported. There are a couple ways to do this. One way is to add a test for the entry point, like for
utils
. Another, more obvious way is to be explicit about which modules are being exported in the entrypoint. Currently we allow wildcard exports. I am proposing we stop doing this and instead prefer named exports.No ESLint rule exists per se to forbid wildcard exports, but evidently you can use
no-restricted-syntax
as a workaround as described here: import-js/eslint-plugin-import#2493 (comment)The text was updated successfully, but these errors were encountered: