Comments (5)
It specifies a package subpath, which we will resolve against the package, considering "exports" if present.
This doesn't seem right tbh. A package author can't write their main
, browser
, etc on the assumption that exports
will be applied on top, so these will point to real file subpaths (eg ./dist/index.js
), and then needing to add those targets (real file paths) to the exports
map would defeat the point of the exports
abstraction.
from metro.
We'll need to check other tools to see how browser
/exports
are expected to interact - there's no spec for this, but apparently we're taking a matching browser
value and looking it up in the exports
map, which must be wrong.
A browser
field match should probably skip exports
in the same way that main
does.
from metro.
There is no spec for this, but we've been building to the expectation that "browser"
(or any other user redirection) does redirect fully. It specifies a package subpath, which we will resolve against the package, considering "exports"
if present.
https://facebook.github.io/metro/docs/resolution/#resolution-algorithm
Changing this behaviour in Metro (so that a mainFields
mapping is a target that bypasses "exports"
) would be non-trivial (given the wide applications of the redirectModulePath
API under the current resolution algorithm).
Ideally, react-dom
should be updated so that the ./server.browser.js
target is accessible. (OR, we should move forward with removing redirectModulePath
in a simplified resolver 😅)
"exports": {
"./server.browser": "./server.browser.js",
+ "./server.browser.js": "./server.browser.js"
},
"browser": {
"./server.js": "./server.browser.js"
},
from metro.
There is no spec for this, but we've been building to the expectation that "browser" (or any other user redirection) does redirect fully.
Is there ecosystem precedent for this? In the absence of a spec we ought to align, and the situation with react-dom
(a reasonably popular package 😅) does suggest it's Metro that's doing something different.
from metro.
Hmm, fair point! This problem blocks stable Package Exports.
I'm thinking:
- For
"main"
,"browser"
, indeed these are pre-"exports"
concepts — we should allow any mapped relative target to be resolved using file resolution (change). - We would still expect other
redirectModulePath
return values (which may be any type of import specifier — e.g. to another package) to consider"exports"
during subsequent resolution (no change).
(⬆️ Within Metro, it's really time to kill off redirectModulePath
IMO.)
from metro.
Related Issues (20)
- zip
- Is metro will support pnpm in the future? HOT 2
- Could not determine the dependencies of task ' :react-native-gesture-handler:generateDebugRFile' HOT 2
- [0.73.x] Metro crashes because of `__loadBundleAsync` HOT 6
- Unable to resolve module stream HOT 4
- [0.80.4] Metro bundle duplicated code when use unstable_enablePackageExports and unstable_enableSymlinks HOT 3
- No matching version found for [email protected] HOT 1
- Unable to resolve module when using symlinks. HOT 6
- error Cannot read properties of undefined (reading 'transformFile'). TypeError: Cannot read properties of undefined (reading 'transformFile') HOT 2
- Metro uses watchman that leaks watched files HOT 2
- Default metro resolver slower than MetroSymlinksResolver in a monorepo HOT 3
- React Native application does not update on many code changes when using vim HOT 4
- esm HOT 1
- Performance regression between 0.73.9 and 0.76.8 HOT 4
- Unable to resolve self-referring "subpath exports" from within a haste module HOT 1
- `nodeModulesPaths` not working as expected with React Native HOT 1
- Cannot read property 'transformFile' of undefined HOT 1
- Including local packages from outside project root. Can we do better?
- [BUG] Terser mangler issue after upgrading to RN 0.74.5
- Problem during ReactNative project deployment for iOS HOT 2
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 metro.