build with esbuild; support Node 18+

[mbostock]

Fixes #850. Fixes #847.

[mbostock]

Some additional learnings…

• We had a number of imports of .json files without import attributes (or assertions). These only worked because tsx is loose, so we have to rewrite them to be explicit to make them standard JavaScript (since esbuild will not rewrite these imports).
• Import attributes are only supported on more recent versions of tsx, so we have to upgrade tsx if we want to continue using it for tests.
• However, more recent versions of tsx break code coverage with c8 (Coverage with c8 and tsx reporting as 100% since version 4.3.0 privatenumber/tsx#433), so this means we don’t have any code coverage… unless we can figure out how to run the tests using esbuild instead of tsx
• It also means we need to upgrade Prettier. But I hate the new ternary formatting introduced in Prettier 3.1 (and more generally I hate the idea that our formatting styles are subject to the whims of the Prettier maintainers, and apparently they can evolve over time, causing churn in our codebase). So either we need to avoid import attributions so we can stick with Prettier <3.1, or plug our noises and upgrade to Prettier 3.1+, or drop Prettier entirely (perhaps in favor of some alternative but I’m not aware of one). I don’t like any of these options. (I’ll also note that there are 100+ // prettier-ignore directives in our repo, but most of them are for long lines in tests.)
• If we drop tsx, then we won’t be able to support TypeScript project configuration files observablehq.config.ts, at least via direct import… so maybe we’ll need to use esbuild to load it on the fly? I guess we can do the latter and it shouldn’t be a big deal because we already have a runtime dependency on esbuild

Update: I bypassed most of this by using process.env.npm_package_version instead, and then baking it in using --define with esbuild. Hooray.

[mbostock]

Oh also, if we use import attributes, then we require Node 20.10 — I think that’s probably too bleeding edge (2023-11-22)? If we use the now-deprecated import assertions (and drop tsx at runtime), we can support Node 18. Maybe we can drop that in favor of process.env.npm_package_version? Not sure if that works in Yarn though… and also it’ll be wrong when Framework is run as a dependency, surely.

Update: process.env.npm_package_version worked great.

[mbostock]

The leading slash here means only ignore build/ at the project root, not test/input/build/ etc.

[mbostock]

I think the remaining issue is that I don’t know how to do the equivalent of $(find …) on Windows. We could use glob, but I still don’t know how to pass the result of that to the esbuild command.

[mbostock]

I think I’ll have to write a script in JavaScript and use esbuild’s JavaScript API so that it works on Windows. 😞

[Fil]

I've tested it as much as I could (and could imagine how to). LGTM.

One thing that I found a bit confusing is that yarn build in this repo builds the documentation site (dist), as an alias of observable build. You need yarn prepublishOnly to build the build folder. Since this is just for us developers of Framework, it's probably OK, but we could also change this either to make it clearer by changing the commands names — or more simply by building both dist and build (it's 0.7s on my machine, so fast that it's not going to be a burden).

[mbostock]

Can you approve if it looks good?

I thought about changing yarn dev to yarn docs:dev etc. but I don’t see a big benefit and it’ll be more disruptive. And I don’t think it makes sense to combine the two unrelated actions into one.

[mbostock]

Like really the current dist should be dist-docs or something, and the current build should be dist… but they’re all just names internal to this repo so I don’t think it matters.

[visnup]

Should we add v18 to the GitHub Actions workflow matrix?