denoland
refactor: complete move to Vite Environment API
I was perusing the code whilst investigating #3606 and noticed that, despite the release post claiming that Fresh had "fully embrace[d]" the Vite Environment API, it was still using ssrLoadModule. Once I started looking, I noticed a bunch of other code that wasn't future-proof (env-wise, not rolldown-wise, which'll bring it's own swath of deprecations[^1]), so I updated them as well.
The newly added source map tests from #3624 currently fail again because the ModuleRunner API at the heart of the Environment API relies on process.setSourceMapsEnabled, which is currently set to no-op in Deno.
[^1]: Separately tried to try out rolldown-vite but it seems that Deno doesn't support aliasing dependencies whatsoever? (I know there's not official support, but I was going to try to edit the lockfile to hack around it; however, it seems that there's not alias support in there at all?)
which is currently set to no-op in Deno
Looked closer, the actual code has a comment saying source maps are always on, so not sure what's up with that?
canary CI ran with https://github.com/denoland/deno/pull/31358 and still failed, not sure what's up. I think it probably makes sense to split out the ModuleRunner commit, merge the others, and figure out the source map failures separately.
I think it probably makes sense to split out the ModuleRunner commit [..] and figure out the source map failures separately.
Filed #3645 for further followup