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
exportsfield supersedes other mainFields, if the tooling supports theexportsfield.exportsis supported since:exports, which is what the majority still uses.@rollupjs/plugin-node-resolvev11.1 (Release: 2021-01-15)package.json#exportsmap parcel-bundler/parcel#4155exportsis still not supported by:eslint-plugin-node-no-unresolvedis not aware ofexportsdefinition inpackage.jsonimport-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/moduleandexports, 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.