Compile to JavaScript and drop runtime dependency on tsx

[mbostock]

I love tsx during development, but I think we should compile to JavaScript on publish and drop the runtime dependency. This would allow us to support Node 18+ instead of requiring Node 20.6+, and it would fix confusing errors such as #847. It would just be “fewer moving parts” and more robust, and it shouldn’t be too technically challenging to run esbuild or tsc or whatever on publish.

[Fil]

This seems like it would help a lot of people. I've experimented a bit with esbuild:

yarn esbuild --target=esnext --outdir=build/ bin/observable.ts src/**/*{js,ts,css} && cp package.json build`

(You can also add --minify and --sourcemap).

I had to specify, in tsconfig.json:

"module": "nodenext",

so that it would compile with top-level await.

But then when I then run:

node build/bin/observable.js preview

I get errors related to package.json [1]. If I force my way around this problem [2], it then fails on observablehq.config.ts (as it only accepts a js config file). If I rename the config file, I then get another error about package.json [3].

It doesn't seem complicated, it's just that I don't really know ho this is supposed to work. Maybe someone with a better knowledge of esbuild will come up with the best approach.

[1] Unexpected error: The requested module '../package.json' does not provide an export named 'version'
[2] for example, with const {version} = (await import("../package.json", {with: {type: "json"}})).default;
[3] Unexpected error: The requested module './package.json' does not provide an export named 'version'

[mbostock]

Some things I learned so far in #963:

• Use find instead of glob (ref. How to translate the entire project directory? evanw/esbuild#263 (comment))
• Drop --target=esnext because it’s the default
• Add --platform=node because we’re not building for the browser

In general it seems to work well, but the fact that the generated sources live in a different directory I think are going to cause problems for methods such as getClientPath which assume they are in src/client/. I also would like our testing and local development environment to be as close as possible to what we publish, so that we are less likely to have issues that only affect the published distribution. esbuild has some lovely built-in watch and serving features for local development, which makes me wonder if we couldn’t just drop tsx entirely? But I also want to minimize churn, so my primary goal for this week is to get a no-tsx distribution working.