Comments (16)
I think we had previously discussed exposing this as module.resolve
which I would not be opposed to. It would be preferable for the semantics of import.meta.resolve
to 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 be import.meta.node.resolve
or import.meta.nodeResolve
Thoughts?
from modules.
The import.meta.resolve()
method has become synchronous in Node v20, but you still need the --experimental-import-meta-resolve
flag.
Synchronous
import.meta.resolve()
In alignment with browser behavior, this function now returns synchronously. Despite this, user loader
resolve
hooks can still be defined as async functions (or as sync functions, if the author prefers). Even when there are asyncresolve
hooks loaded,import.meta.resolve
will 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
from modules.
Because import.meta.resolve
is 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.
from modules.
Also I do think it's a critical part of the implementation since require.resolve
is 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.
from modules.
I've added the meeting agenda label, let's try to discuss this further.
from modules.
I think we had previously discussed exposing this as
module.resolve
which 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.resolve
could be either or even take the context as another argument if we wanted. E.g. module.resolve(specifier, contextURL, contextConditions = ["require"])
or module.resolve(specifier, contextURL, fromRequire = true)
.
from modules.
I do like the API being usable to determine either require or import personally.
from modules.
The major blocker to import.meta.resolve
is 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.resolve
and import.meta.resolve
, or do you mean enabling an option into the resolve function?
To explain the benefits of import.meta.resolve
over 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.resolve
expression 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.
from modules.
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.
from modules.
Removing from agenda for now. We can bring this up again if we want to revisit
from modules.
just ran into this again and the "hack" won't work anymore π
e.g. require.resolve(path.join(pkgName, 'package.json'));
will fail if the pkgName
has exports in the package.json
defined.
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.json
to 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_modules
sooo 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 π€
from modules.
I ran into this issue where require.resolve
would not find an ESM .js
file, so I fell back on using https://github.com/wooorm/import-meta-resolve for now, until import.meta.resolve
is officially available. Or is it a reasonable requirement to ask people to always use the --experimental-import-meta-resolve
flag when using certain libraries in the Node.js ecosystem?
from modules.
Or is it a reasonable requirement to ask people to always use the
--experimental-import-meta-resolve
flag 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)
from modules.
same issue here, why was this closed?
from modules.
This is resolved by 20.6.0 whenever it ships.
from modules.
Thanks!
from modules.
Related Issues (20)
- Mocking use cases HOT 13
- Relaxing the '#' restriction on imports HOT 8
- Node.js Modules Team Meeting 2020-09-09
- Node.js Modules Team Meeting 2020-09-23 HOT 1
- Document node: scheme HOT 4
- Clarification for bundlers re "import" / "require" matching HOT 7
- Node.js Modules Team Meeting 2020-10-07 HOT 3
- File URL normalization changes HOT 1
- s/master/main HOT 3
- Node.js Modules Team Meeting 2020-10-21 HOT 4
- Experimental Status HOT 18
- Node.js Modules Team Meeting 2020-11-04
- Archiving modules repo and stopping team meetings HOT 1
- Use existing context for SourceTextModule evaluation? HOT 2
- Node.js Modules Team Meeting 2020-11-18
- import local files fails while import() succeeds HOT 5
- Proposal: ESM should not export PromiseLike instance HOT 5
- `import.meta.url` is `undefined` inside module file. HOT 3
- Extensionless files should allow --input-type (or work) HOT 14
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from modules.