Edge environment package export map
Unanswered
Eric Burel posted this in #help-forum
Hi folks, do you know if there is a way to differentiate Node.js and Edge from a 3rd party package.json standpoint? Like
React has "poisoned" exports https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md#poisoned-imports for server components, but Next doesn't seem to have an edge vs node equivalent?
Just to elaborate : it's easy to add different "node" and "edge" export, the problem is about having Next.js to pick up the right one automatically during build. I am coding a debug package that is meant to be used in deeply nested code where you can't tell whether you are in an edge rendered page/middleware or Node.js, I'd be eager to load the right code automatically.
Currently I bypass the issue with a conditional import but this is not scalable and clumsy.
exports: {node:foobar, edge: foobar-edge-friendly.js} ?React has "poisoned" exports https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md#poisoned-imports for server components, but Next doesn't seem to have an edge vs node equivalent?
Just to elaborate : it's easy to add different "node" and "edge" export, the problem is about having Next.js to pick up the right one automatically during build. I am coding a debug package that is meant to be used in deeply nested code where you can't tell whether you are in an edge rendered page/middleware or Node.js, I'd be eager to load the right code automatically.
Currently I bypass the issue with a conditional import but this is not scalable and clumsy.
13 Replies
@Eric Burel Hi folks, do you know if there is a way to differentiate Node.js and Edge from a 3rd party package.json standpoint? Like `exports: {node:foobar, edge: foobar-edge-friendly.js}` ?
React has "poisoned" exports https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md#poisoned-imports for server components, but Next doesn't seem to have an edge vs node equivalent?
Just to elaborate : it's easy to add different "node" and "edge" export, the problem is about having Next.js to pick up the right one automatically during build. I am coding a debug package that is meant to be used in deeply nested code where you can't tell whether you are in an edge rendered page/middleware or Node.js, I'd be eager to load the right code automatically.
Currently I bypass the issue with a conditional import but this is not scalable and clumsy.
i think it is
interestingly we also have
edge-light for Vercel Edge specifically https://runtime-keys.proposal.wintercg.org (i found this from inspecting edge-compatible packages released by Vercel).interestingly we also have
edge in @vercel/og: https://www.npmjs.com/package/@vercel/og?activeTab=code. so i think it's best to just do whatever @vercel/og does:{
"exports": {
".": {
"edge": {
"types": "./dist/index.edge.d.ts",
"default": "./dist/index.edge.js"
},
"edge-light": {
"types": "./dist/index.edge.d.ts",
"default": "./dist/index.edge.js"
},
"browser": {
"types": "./dist/index.edge.d.ts",
"default": "./dist/index.edge.js"
},
"worker": {
"types": "./dist/index.edge.d.ts",
"default": "./dist/index.edge.js"
},
"workerd": {
"types": "./dist/index.edge.d.ts",
"default": "./dist/index.edge.js"
},
"import": {
"types": "./dist/index.node.d.ts",
"default": "./dist/index.node.js"
},
"node": {
"types": "./dist/index.node.d.ts",
"default": "./dist/index.node.js"
},
"default": "./dist/index.node.js"
},
"./package.json": "./package.json"
}
}Finally found the same link at the same time it was hidden in the docs, much thanks!
I am giving it a shot, TS is not happy yet but might be my config
This seems not officially documented yet
Yeah it seems that "bundler" moduleResolution doesn't find the types then
ok my bad I need a nested export
first "."' default, then the runtime key
and also I need to use "Bundler" module resolution in the importing package
interesting
I needed to add "types" too
but that makes sense because vs code can't tell if you use "node" or "edge" so you must tell what types you want as a default
"default" has the same effect it seems