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
Given the state of support, perhaps we have to wait a bit longer. Because many packages will have both main/module and exports, and suggesting this would be a huge breaking change without much benefit.
I think there's now enough support to start providing this suggestion. There's still the concern that it's totally fine to keep using the main fields just in case, but I think this is a good nudge towards a single way to export things, and will help simplify library publishing in the future.
The
exports
field supersedes other mainFields, if the tooling supports theexports
field.exports
is supported since:exports
, which is what the majority still uses.@rollupjs/plugin-node-resolve
v11.1 (Release: 2021-01-15)package.json#exports
map parcel-bundler/parcel#4155exports
is still not supported by:eslint-plugin-node
-no-unresolved
is not aware ofexports
definition inpackage.json
import-js/eslint-plugin-import#1810 (new fork should be used instead: https://github.com/eslint-community/eslint-plugin-n)Given the state of support, perhaps we have to wait a bit longer. Because many packages will have bothmain
/module
andexports
, and suggesting this would be a huge breaking change without much benefit.I think there's now enough support to start providing this suggestion. There's still the concern that it's totally fine to keep using the main fields just in case, but I think this is a good nudge towards a single way to export things, and will help simplify library publishing in the future.
This suggestion is initially brought up in #21.
The text was updated successfully, but these errors were encountered: