Support import.meta.resolve

[grainstackdev]

This exports field is needed for import.meta.resolve to find the file location of a node_modules import.

exports: https://nodejs.org/api/packages.html#exports
import.meta.resolve: https://www.npmjs.com/package/import-meta-resolve

I need this in order to get my package web-imports to bundle my other package grainbox properly for CDN usage.

[ljharb]

Note that adding "exports" is a breaking change, and to be maximally backwards compatible you need a string fallback, as well as the "default" condition specified.

Also, as-is, this will break, so here's how you'd need it to look:

Suggested change

	"exports": {
	"import": "./dist/qss.mjs"
	},
	"exports": {
	".": [
	{
	"import": "./dist/qss.mjs",
	"require": "dist/qss.js",
	"default": "dist/qss.js"
	},
	"dist/qss.js"
	],
	"./package.json": "./package.json"
	},

[grainstackdev]

Whoa, thank you for catching that.

[lukeed]

Array exports are the least compatible of all types. Please prepare an object only. As mentioned, this is a breaking change by the mere presence of “exports” alone due to wildly varying resolution support across early Node versions, so not going to step into “exports” territory with the buggiest/least-supported 1st foot.

[ljharb]

@lukeed i'm not sure what you mean, every single implementation of the "exports" field i'm aware of supports array fallbacks, and i use it on hundreds of packages with zero reported issues.

[grainstackdev]

I have added more commits.
Changes:

• Added a .cjs file so that require from a type: module can work. I.E. fixes error: "To treat it as a CommonJS script, rename it to use the '.cjs' file extension."
• Now using .mjs instead of .m.js to be consistent. Currently, there is a dist/qss.mjs but I couldn't figure out how it gets generated, so instead, I just renamed the only file I could see, .m.js to .mjs.
• The exports object is only using features written here: https://nodejs.org/api/packages.html#exports. I couldn't find docs on using arrays, so I don't feel too confident using them.
• The exports object allows direct importing of the full file path, including extension. I think this should make it backwards compatible.
• I tested and found these working:
  • importing from a type: module project
  • requiring from a type: commonjs project
  • direct imports to full path w/ extension

[ljharb]

Note that without the array, the engines field should be modified to exclude node 13.0-13.2.

[lukeed]

I went with my usual exports mapping & made sure to include the types condition. This will be a 3.0

Thanks~

[ljharb]

without "default", it won't work in a number of node versions included in your engines declaration. can you add that?

[lukeed]

Every node resolver always either has import or require flagged. This is true for all node versions I’m aware of.

[ljharb]

It's not true for node 13.3 - 13.6 (node 13.0-13.2 only support the string form, but do support array fallbacks).

Your engines say >= 4, which explicitly includes these versions.

[ljharb]

You can peruse the test cases in https://www.npmjs.com/package/node-exports-info if you like :-)

[grainstackdev]

Thanks!!