Open nbrugger-tgm opened 1 month ago
I see.. I wonder if this was to try to homogenize all the fetch on the web version.. I don't think Start does this but Vinxi might be. Actually the fact this happens in build makes me possibly suspicious of Nitro here.
To share some information to help trace this, it might be coming from unenv
which Nitro uses. I've experienced similar behaviour in build.
You may consider doing this to circumvent the automatic replacement
export default defineConfig({
server: {
alias: {
"node-fetch": "node-fetch",
},
},
});
Where would I have to do this? vinxi.js? Vite plugin?
Where would I have to do this? vinxi.js? Vite plugin?
In app.config.ts
Duplicates
Latest version
Current behavior 😯
When importing and using APIs like
import fetch from "node-fetch";
the types, and APIs that are used at runtime WILDLY differ betweennpm run dev
andnpm run build && node .output/server/index.mjs
.Observed differences:
await fetch(myUrl, { compress: false });
run dev
: the response returned is as expected not decompressed when using.arrayBuffer()
run build
: the response ignores the compress option and decompresses the response of.arrayBuffer()
NodeJS.ReadableStream
(console.log(await fetch(myUrl).body
)run dev
run build
In general it seems that at runtime (
npm run build
)import fetch from "node-fetch";
thefetch
is replaced with the browser/DOMfetch
API which does not happen atnpm run dev
.Expected behavior 🤔
When importing
import fetch from "node-fetch";
the output and behaviour of the API innpm run dev
andnpm run build
is completely the same. While implementation might change behind the scene on building behaviour and API contracts shall not be broken.Steps to reproduce 🕹
Steps:
npm install && npm run dev
goto localhost:3000 see the Content size + body prototypenpm run build && node .output/server/index.mjs
repeat and see the differenceContext 🔦
There are features in the
node-fetch
fetch not present in the browser / domfetch
(the compress option).Your environment 🌎