Repository navigation
Enabling import meta resolve by default? #550
Description
Activity
Because
import.meta.resolveis a common API between platforms, we need some interest from other implementers before unflagging.Domenic has made a similar proposal for the browser with roughly the same API, but as a synchronous variant - whatwg/html#5572. The sync / async concern between browsers and Node.js is a tricky one to get agreement on, which is tricky without any open standards space to truly discuss this stuff.
I've posted an issue to Deno to see if there is interest here - denoland/deno#7296.
Also I do think it's a critical part of the implementation since
require.resolveis such a standard workflow in CommonJS. I really hope we don't allow the lack of collaborative standards in the cross-platform modules space to slow this down.I've added the meeting agenda label, let's try to discuss this further.
I think we had previously discussed exposing this as
module.resolvewhich I would not be opposed to. It would be preferable for the semantics ofimport.meta.resolveto be similar cross platform, although I do recognize that import.meta is intended to be a bag for embedders to put things on. Another alternative could beimport.meta.node.resolveorimport.meta.nodeResolveThoughts?
Reacted by Jordan Harband, Owen Buckley and LEE HYEONUI think we had previously discussed exposing this as
module.resolvewhich I would not be opposed to.One minor thing consideration there is conditional resolution.
import.meta.resolve"clearly" uses import-relative resolution.require.resolve"clearly" uses require-relative resolution.module.resolvecould be either or even take the context as another argument if we wanted. E.g.module.resolve(specifier, contextURL, contextConditions = ["require"])ormodule.resolve(specifier, contextURL, fromRequire = true).I do like the API being usable to determine either require or import personally.
The major blocker to
import.meta.resolveis the sync / async issue between what is proposed for the browser and what is needed for Node.js. What do people think about just making this sync to align with Domenic's proposal and to try and move forward with that?@bmeck do you mean via the distinction of
require.resolveandimport.meta.resolve, or do you mean enabling an option into the resolve function?To explain the benefits of
import.meta.resolveover a custom resolver, it's worth mentioning https://github.com/vercel/webpack-asset-relocator-loader.Consider loading a template:
const template = await (await fetch(await import.meta.resolve('pkg/template.html')).text();
It is possible for the build tool to use the
import.meta.resolveexpression as something to statically analyze to determine that an asset is being referenced, and then rewrite this in the build to something like:const template = await (await fetch(import.meta.url + '../assets/template.html'))
where assets are relocated by the build process based on their references.
The other benefit is that this resolver pattern can be transferrable between runtimes, instead of needing some advanced "superResolve" library that can work cross-environment.
do you mean via the distinction of require.resolve and import.meta.resolve, or do you mean enabling an option into the resolve function?
I mean having 1 function that I can throw data into that handles all the basic resolutions I might be curious about. This is not in any way critical as if we have N functions I can just wrap them into a single function anyway.
Removing from agenda for now. We can bring this up again if we want to revisit
just ran into this again and the "hack" won't work anymore 😅
e.g.
require.resolve(path.join(pkgName, 'package.json'));will fail if thepkgNamehas exports in thepackage.jsondefined.And I guess basically, no one will have an export map like
"exports": { "package.json": "./package.json" }
what I want to do is read the
package.jsonto create an import map based on the exports in there.My idea is to resolve the package directory and then do a regular
fs.readFile. Why do I want to use the node solution for that? I am not sure in which node_modules folder my package is... e.g. is it in the root or in some nested node_modulessooo is there any other way to resolve the package directory?
strawman proposal
const pkgPath = import.meta.resolvePackage('@foo/bar'); // <<<<------ new method? const pkgJsonStream = await fs.promises.readFile(path.join(pkgPath, 'package.json')); const pkgJson = JSON.parse(pkgJsonStream.toString()); const keys = Object.keys(pkgJson.exports); for (let i = 0; i < keys.length; i += 1) { const exportKey = keys[i]; const exportValue = pksJson.exports[i]; // add exportsKey to import map // resolve dependency package? - e.g. check if it's also in the root or a sub node_modules folder const dependency = mport.meta.resolvePackage('@foo/bar', exportValue); // ... recursive go through dependency tree }
hmmm or would it better to "just" walk the node_modules folders myself 🤔
I ran into this issue where
require.resolvewould not find an ESM.jsfile, so I fell back on using https://github.com/wooorm/import-meta-resolve for now, untilimport.meta.resolveis officially available. Or is it a reasonable requirement to ask people to always use the--experimental-import-meta-resolveflag when using certain libraries in the Node.js ecosystem?Or is it a reasonable requirement to ask people to always use the
--experimental-import-meta-resolveflag when using certain libraries in the Node.js ecosystem?It’s not reasonable to ask users to use any experimental feature. By definition, experimental features could change or disappear at any time.
This one in particular seems unlikely to ship in its current form, per whatwg/html#5572 (comment)
same issue here, why was this closed?
The
import.meta.resolve()method has become synchronous in Node v20, but you still need the--experimental-import-meta-resolveflag.Synchronous
import.meta.resolve()In alignment with browser behavior, this function now returns synchronously. Despite this, user loader
resolvehooks can still be defined as async functions (or as sync functions, if the author prefers). Even when there are asyncresolvehooks loaded,import.meta.resolvewill still return synchronously for application code.Contributed by Anna Henningsen, Antoine du Hamel, Geoffrey Booth, Guy Bedford, Jacob Smith, and Michaël Zasso in nodejs/node#44710
Reacted by Jacob HummerThis is resolved by 20.6.0 whenever it ships.
Thanks!
When using esm there seems to be no way to resolve paths to a packages 🤔
In a commonjs project, I currently have this "gem" 😅
with
--experimental-import-meta-resolveI can basically replaceresolvedNodePackagePathwithawait import.meta.resolve(...).However, as long as it's an experimental flag it is kind of a tough sell to users and additionally, it requires some trickery for
bins😅So hence my question any chance this is going to be unflagged any time soon?