You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #2490 it was discussed that depending on code in deno_std as part of Deno is "problematic" because we can't easily get rollup to support extensioned TypeScript. With the deno bundle feature landing, we could in theory for most/all of our internal code bundles use Deno itself to generate its own bundles.
There are a couple considerations:
currently bundle source maps aren't parsed out and made available inside Deno. This is talked about in Bundling V2 #2475, but we don't have this yet. We would want that to see where in the bundle internal code "broke" or participated in a stack trace.
we would have to embed a bundle loader into the bundle/snapshot.
The text was updated successfully, but these errors were encountered:
For future generations, the need to generate a bundle was removed from the build process, versus actually generating it using the bundling capability of Deno.
In #2490 it was discussed that depending on code in
deno_std
as part of Deno is "problematic" because we can't easily get rollup to support extensioned TypeScript. With thedeno bundle
feature landing, we could in theory for most/all of our internal code bundles use Deno itself to generate its own bundles.There are a couple considerations:
The text was updated successfully, but these errors were encountered: