Support for `module` field

[fregante]

The package webext-dynamic-content-scripts does not have a main file but only a module file.

eslint-plugin-import is marking it as:

Unable to resolve path to module webext-dynamic-content-scripts.  import/no-unresolved

Example:

import i from 'webext-dynamic-content-scripts';
i();

For reference, both webpack@2 and rollup (+ its node resolution plugin) can successfully bundle it:

npm i rollup
npm i rollup-config-webext # configuration for npm resolution
npm i webpack

echo "import i from 'webext-dynamic-content-scripts';i()" > input.js;

rollup --config node:webext input.js
webpack a.js b.js && cat b.js

[ljharb]

This isn't a standard field, it's not one node will ever support, and it's a field that tools that currently support it (including webpack) will all definitely eventually drop once node ships native module support.

I don't think it's a good idea to support it now, and I think it's a bug that https://github.com/bfred-it/webext-dynamic-content-scripts doesn't have a "main" field.

[fregante]

Hmm I guess you're right about the module field since node is going for .mjs.

I suppose I'll add a UMD file there then.

[ljharb]

That's better than nothing; I'd suggest never using a UMD either. Just use a normal ES5 CJS module for "main", and let consumers handle module format in their bundler.

[fregante]

The package is mostly for the browser extensions, so honestly I don't expect many people using bundlers with it, even fewer using non-esm bundlers. UMD is ok for me at this point, even though I generally don't use it either.

[ljharb]

¯\_(ツ)_/¯ k, but anyone not using a bundler with anything in the browser, even extensions, is making a mistake.