The ES module points to non-transpiled src/core.js file

[maxart2501]

The ES module points to non-transpiled src/core.js file

[MaxArt2501]

I claim no responsibility for what webpack does :| But you can configure it to compile certain modules in node_modules.
Granted that last time I wrote that part in the package.json for this library it wasn't clear at all what the "module" property would have implied, as it is you can do this:

import shareThis from 'https://cdn.jsdelivr.net/npm/share-this/src/core.js';

and that would work perfectly fine.

But I guess I'll look into what's rolling now for those package.json properties, and serve a single file compiled for ES6 in "module"...

[markogresak]

I claim no responsibility for what webpack does

To clarify, it's not just webpack, any "standard" bundler implementation where we use import ... from ... will behave this way. It's even mentioned in the Node.js docs https://nodejs.org/api/esm.html#esm_dual_commonjs_es_module_packages

Prior to the introduction of support for ES modules in Node.js, it was a common pattern for package authors to include both CommonJS and ES module JavaScript sources in their package, with package.json "main" specifying the CommonJS entry point and package.json "module" specifying the ES module entry point. This enabled Node.js to run the CommonJS entry point while build tools such as bundlers used the ES module entry point, since Node.js ignored (and still ignores) the top-level "module" field.

So from this point of view, the use of "module" is not correct, it should be "exports". But it's the de-facto way with bundlers.

Also, the bug I have reported here is the problem node.js docs call "dual package hazard": https://nodejs.org/api/esm.html#esm_dual_package_hazard.

So what I've suggested with option 2), removing the "module" bit sounds like the best option. Or it could be changed to "exports".