`deno` support?

deno seems like a great environment for running ink, as it aims to be a simple, secure, and fast way to ship JavaScript executables to users while being extremely light in setup for developers. Looking at ink and putzing around a bit (I’m admittedly pretty new to deno and ink), it seems that there are a few issues with its current setup that make it difficult to use with deno:

1. ink does not publish a version of itself as a bundled ESM. deno requires that packages be consumed as ESM, and that ESM would likely have to have bundled with it all of inks dependencies. To fix that would require introducing an ESM bundling step as part of the build for the package, using something like rollup. I took a quick stab at doing that in a fork, which can be found here. The fork successfully bundles but still does not work in deno.
2. Once the ESM bundle is being published as part of the build, the simplest way to vend that bundle would be to just point to the generated bundle using the "module" field in package.json. Then package managers and CDNs that vend ES6 modules, like pika.dev, could pick up ink and serve the ESM bundle. Note how currently pika.dev has ink listed but cannot serve it because there is no "module" field in the package.json.
3. Any dependencies that ink or its npm dependencies have on the Node standard library or Node-specific runtime behavior may need to be refactored to accommodate a deno environment. See here for the deno standard library. It does deviate somewhat from the Node standard library. I have not taken the time to actually identify which libraries or parts of ink might fall under this category, but this could be the largest chunk of work to provide deno support and will potentially involve updating multiple libraries.

Have any of the library maintainers considered deno support? Points (1) and (2) seem valuable in general, even outside of a goal of deno support, as moving the JS ecosystem towards an ESM-first world will make a big impact in the usability of libraries in a more progressive, lightweight manner. However, with deno, getting up and started with ink could be as simple as (sloppily adapting the Counter demo):

import React from 'https://cdn.pika.dev/react/latest';
import {render, Color} from 'https://cdn.pika.dev/ink/latest';

const Counter = () => {
	const [counter, setCounter] = React.useState(0);

	React.useEffect(() => {
		const timer = setInterval(() => {
			setCounter(prevCounter => prevCounter + 1);
		}, 100);

		return () => {
			clearInterval(timer);
		};
	});

	return (
		<Color green>
			{counter} tests passed
		</Color>
	);
};

render(<Counter/>);

Note that the code hasn’t changed much, but the real difference is that this one file would be the entire project for getting started with an ink app. No package.json, no Babel, no Typescript compiler, no need for associated code generators like create-ink-app. It would allow new developers and folks just experimenting to use ink much more quickly and easily.

Comments? Thoughts?

[vadimdemedes]

Going to re-open this issue to increase visibility.

[Songkeys]

Hi! It’s been a year. Deno has published its official 1.x version as well. Since v1.7, we can even compile a deno project into a single binary file. I’d be much happy to see ink supporting it! Any plan so far?