As a sanity check I looked at what some of the other Yargs libraries have, and import entry point and "module" do match each other.

https://github.com/yargs/yargs-parser/blob/3aba24ceaa1a06ceb982c63a06002526d781e826/package.json#L6-L19

https://github.com/yargs/cliui/blob/af3145da0ea31738c4715865a6da0ee388a94c74/package.json#L6-L16

I note you put fix! for a breaking change in the title. Do you feel it is a breaking change, or is it just a bug fix?

(I don't have much experience with bundlers and interested in your reasoning.)

@shadowspawn
Thank you for reviewing! You can remove !.

I added it because this PR may break environments using older versions of bundlers that don't support the exports field.
I don't know how many users use this package directly and are impacted.

I checked when webpack and rollup started supporting exports.

• webpack: from webpack 5 Respect "exports" field in "package.json" webpack/webpack#9509
• rollup: from 2020, Support "exports" field in package.json rollup/plugins#208

Thanks for info, and good links.

I found a couple of links covering background and usage of the "module" main field:

• https://stackoverflow.com/questions/42708484/what-is-the-module-package-json-field-for
• https://esbuild.github.io/api/#main-fields

@shadowspawn

Thank you for letting me know!

• I understand the module field is not official, but major bundlers supported it in old versions.
• Also, I found y18n has 1,048 dependents.
• The only action the users should take is to change the named import to the default import

Now, my idea...

1. Release with fix, because it changes the interface for old bundlers, but the user impact is small
2. Release with fix!, even if user impact is small
   1. I think it's nice to drop Node 10 and 12 on the same major update.

I respect your decision.