Explicitly set entry point for Deno, to not load browser version by default

[Stephan-C]

Feature Use Case

The assumption made here: #3634 was to load the browser version by default for Deno targets. However, this is not always the best scenario. There are many cases where the browser version will need access to the DOM, where the node (server) version or an alternative entry point will be more suited for loading into Deno.

Feature Proposal

Add a way to explicitly set the the entry point for Deno targets, which overrides loading the browser entry point on Deno.

[dnalborczyk]

curious how deno loads npm modules in the first place. do you mean with the (in development) compatibility layer?

there seems to be a promoted deno flag: https://nodejs.org/dist/latest-v17.x/docs/api/packages.html#community-conditions-definitions

[lukastaegert]

For that, we would need to know what a "better" entry point for Deno would be. The Node build imports Node internals like path and fs. I would be surprised if that worked in Deno, but actually I have no idea how to do stuff in Deno.

Curious where Rollup "needs access to the DOM", you are saying there are "many cases"?

[Stephan-C]

I didn't say rollup needs access to the DOM. I said the browser entry point setting is the default entry point on Deno when loading a library that was packaged with Rollup. There should be some override to specify the entry point for a Deno target, explicitly.

You can load npm packages into Deno using, e.g. Skypack, jspm.io, jsDelivr, esm.sh, etc.

[Stephan-C]

Webpack allows you to set the Deno target environment entry point: https://webpack.js.org/guides/package-exports/#target-environment

[lukastaegert]

I said the browser entry point setting is the default entry point on Deno when loading a library that was packaged with Rollup. There should be some override to specify the entry point for a Deno target, explicitly.

How would Rollup set the entry point of a package? Rollup core is only outputting JavaScript by default, it does not write e.g. package.json files. I have not the slightest idea what you actually expect Rollup to do.

[Stephan-C]

Yeah, sorry, this might be something in a rollup plugin, I will have a look at the plugins used. The only reason why I linked that PR, is because that is the only place I could find a reference to the browser version loading by default in Deno, #3634 (comment) . Nowhere else I could find something similar to the issue I'm trying to solve. I'm still new to Rollup and trying to find solutions for this issue: remarkablemark/html-dom-parser#181

[guybedford]

If you add a "deno" condition in the exports field, and configure this with rollup-plugin-node-resolve as an exports condition, that is one technique that can work here and that we use in JSPM.

[frank-dspeed]

@lukastaegert good news i have one time refactored rollup for use with deno it was relativ easy i splited the node dependencies into a own package and i import them from there after that i created the same package with the same api's but used the deno compatible dependencies it is not much needed FS Path thats it deno can do the rest out of the box

deno

deno uses internal a bundler to prepare the code to get runned (download, cache, build) it runs ECMAScript2022+ Everything that is not a NodeJS Core Module and is ECMAScript works you can see deno as browser but with the ability to load nativ code

Historycal it was Parcel today they are trying to build on top of the SWC Tools (Acorn written in Rust) but parcel is still the default bundler

rollup watch is the only problematic part so when we would publish the esm version with 2 additional files that can get conditional imported that load the rollup.js and inject the dependencies we are done

GraalVM/GraalJS

A ECMAScript 2021 compliant JavaScript implementation built on GraalVM. With polyglot language interoperability support. Running Node.js applications!

Acorn at present performs really bad in GraalVM but rollup works great the GraalVM Team is working on some compiler optimizations to get the acorn code run more performant because it branches always new objects there are compiler problems with the cache v8 some how works around that.

exports in package.json

Deno and GraalVM do not support the package.json importMaps both do support ECMAScript nativ importMaps by default