support package.json "exports"

[chase-moskal]

i think importly currently only works with the "main" field, eg, "main": "./x/index.js" — iirc, we also support "module" field...

we really should add support all this newfangled "exports" field

• https://nodejs.org/api/packages.html#exports
• https://webpack.js.org/guides/package-exports/
• https://medium.com/swlh/npm-new-package-json-exports-field-1a7d1f489ccf

i'm pretty sure importly will fail to provide a correct importmap for packages that are using this standard..

amazingly, despite it apparently being around since node 12, i haven't personally encountered this problem in the wild yet, but i recently learned about tsconfig nodenext, and that led to this, so i've been thinking about this lately..

five minutes later...

yikes, there's also all this crazy "imports" field stuff too...
do we need this also? i mean there's #dep syntax and wildcards/*.js :scream:

why did they have to do this to me? :skull:

i think i'm going to ignore and procrastinate this issue until the exact last microsecond before some important package i rely on forces me to implement this in order to use it. for now, i'll stick to "main", and for anything outside that, i'll reference the damn .js manually..

eg, @benev/construct/mini might have to be @benev/construct/x/mini.js as a workaround...

meanwhile, if any damn package in my dependency graph requires the funky "import" field mappings in order to work, everything will explode... yikes man.. you know, the nodejs team better have made library that can magically handle all this funky stuff or my head will explode..

lukeed's resolve.exports!! :clap: :clap:

configurable "exports" and "imports" resolver

hell yeah!! it even does the imports!?!?! :sunglasses: :sunglasses:

if this fella did this not in an official capacity for the nodejs team — then that's negligent malpractice on node's part — and this guy deserves a gold medal and a briefcase full of money :laughing: