bluwy
Suggest remove `main` and `module` if have `exports`
The exports field supersedes other mainFields, if the tooling supports the exports field.
exports is supported since:
- Node.js v12.7 (Release: 2019-07-23) (history)
- Around the same time when ESM support is stabilized (history)
- Earliest ESM support is v8.5, but adoption could be considered low as it was experimental until v12.20
- Webpack 5 (Release: 2020-10-10)
- Webpack 4 does not support
exports, which is what the majority still uses.
- Webpack 4 does not support
@rollupjs/plugin-node-resolvev11.1 (Release: 2021-01-15)- Parcel 2.9.0 (Release: 2023-05-26) - https://github.com/parcel-bundler/parcel/issues/4155
- Other recent tooling should support this by default.
exports is still not supported by:
eslint-plugin-node- https://github.com/import-js/eslint-plugin-import/issues/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 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.
This suggestion is initially brought up in #21.
I feel like the safest setup is to keep both main and exports, just in case the project is pretty old — like using Node < 12 or some older webpack project.
or maybe there could be a way to check if the project is actually targeting Node > 12 before showing this warning.
Yeah I think we can check engines.node to test the support range, but even without it set I think the tooling that don't support exports are far back now that it's ok to always suggest it. But we can consider omitting the suggestion if the library has explicitly set to support Node <12.