Comments (8)
What behavior are you looking for?
moduleResolve
is an internal Node API that could be useful, but you have to do more things. You probably have to specify conditions, for example.
If you do:
console.log(moduleResolve('@isnotdefined/stylelint-plugin', new URL(import.meta.url), new Set(['node', 'import'])))
It works.
from import-meta-resolve.
It looks like the docs do currently say that node, import
is the default in moduleResolve
.
Looking through the initial code here added 3 years ago, that seems to be incorrect: that is the default for resolve
, but not for moduleResolve
.
I can remove that in the docs. Is that okay?
from import-meta-resolve.
I think the default options should be same? Or why not?
I use moduleResolve
in many packages, and the default conditions make more sense IMO.
from import-meta-resolve.
why not
It’s an internal API that allows you to specify conditions
and preserveSymlinks
and you get more errors.
I think it’s the other way around: use resolve
. If that is not enough (because you need conditions
/preserveSymlinks
/etc), then you can use moduleResolve
. To pass new Set(['require', 'browser')
for example.
I think the default options should be same?
I’m not really against this idea, but it’s also maybe a breaking change? So changing the docs to match the code (default:
-> example:
) seems safer.
from import-meta-resolve.
It says , so I'd prefer to use moduleResolve
does more things than resolve
that's why it's slowermoduleResolve
over resolve
.
(It seems I misread lower
as slower
😅, but I looked through the source codes, it seems resolve
catches some moduleResolve
error silently)
And also considering the most usage case should use moduleResolve
same as resolve
, so I believe a breaking change to align the defaults is more worth.
from import-meta-resolve.
And also considering the most usage case should use moduleResolve
99% of users should not use moduleResolve
.
It exposes internals that could be useful if you need them. But you probably don’t?
Perhaps this is not explained well in the docs.
This package is about import.meta.resolve
, which is the resolve
function.
Even if we change the conditions
default to match the docs, you should likely use resolve
, and the docs should discourage moduleResolve
.
from import-meta-resolve.
Even if we change the
conditions
default to match the docs, you should likely useresolve
, and the docs should discouragemoduleResolve
.
We're using moduleResolve
because we want to catch all errors manually, and fallback to other files for compatibility:
When I change to use resolve
, there are test cases failing unexpectedly.
from import-meta-resolve.
When I change to use resolve, there are test cases failing unexpectedly.
They are different indeed. That does not necessarily mean you should use moduleResolve
.
resolve
does not throw an error when resolving something that does not exist.
This was changed in Node.js recently, because browser (have to) work like that too. new URL()
works like that too: new URL('/does-not-exist', 'https://example.com')
does not check if there is a https://example.com/does-not-exist
exists. So import.meta.resolve('/does-not-exist', 'https://example.com')
and resolve('/does-not-exist', 'https://example.com')
work like that too.
To use resolve
to find only files that exist, you must then check if files exist.
Similar to what you do on L36: https://github.com/conventional-changelog/commitlint/blob/c085cff2a43003ca40331c12fddf47ee10a9bfd2/%40commitlint/resolve-extends/src/index.ts#L36.
from import-meta-resolve.
Related Issues (18)
- Issues with loading from ESM, "type": "module", & rollup HOT 2
- Enabling usage of this package in an eslint plugin HOT 8
- Support for TypeScript files HOT 13
- Use module.builtinModules instead of builtins dependency HOT 1
- how to resolve named exports? HOT 5
- Yarn PnP compatibility? HOT 18
- Want help on maintenance? HOT 4
- Circular dependency in lib/get-format.js HOT 1
- `import.meta.resolve` is now defined to be _sync_ HOT 1
- Possible to use worker threads and execArgv? HOT 14
- exporting the `packageResolve` function HOT 2
- Support for resolving modules from folder paths HOT 8
- First item is always resolved when export map target is Array (even if non-existent) HOT 8
- Resolve fails on MacOS and Windows, works on linux HOT 7
- Incompatible with yarn P'n'P HOT 12
- Make this work with yarn berry (aka yarn 2/3/4) HOT 7
- [DEP0180] DeprecationWarning: fs.Stats constructor is deprecated in Node v22.0.0 HOT 4
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 import-meta-resolve.