only include needed bundles

[mbostock]

Fixes #688. The tricky part here is FileAttachment. Unlike everything else, we can’t strictly know statically which method you’re going to call to load the file, and therefore which library we need to load. The association is:

method	library
FileAttachment.csv	npm:d3-dsv
FileAttachment.tsv	npm:d3-dsv
FileAttachment.arrow	npm:apache-arrow
FileAttachment.parquet	npm:apache-arrow and npm:parquet-wasm
FileAttachment.sqlite	npm:@observablehq/sqlite
FileAttachment.xlsx	npm:@observablehq/xlsx
FileAttachment.zip	npm:@observablehq/zip

It’s not the end of the world if we don’t preload npm:d3-dsv for example (at least until we want to support self-hosting of libraries #20), but it’s still nice to preload it if we know you’re going to load a CSV file. But if we don’t detect that you need npm:@observablehq/zip for example, then your built site will be broken, because that library doesn’t actually exist (yet) on npm — it’s built locally and self-hosted. (We do plan on publishing it to npm eventually, but it’s a little tricky as it depends on releasing a new version of @observablehq/stdlib and I’m not in a rush to do a major version bump there until we’re a little farther along in bringing Observable notebooks up to parity with Observable Framework.)

So, here are some options:

1. We could always include sqlite, xlsx, and zip. That’s not ideal but it ensures things work. But we wouldn’t want to preload these always, so it means we also don’t have any library preloading based on what files you’re using, which is a slight bummer.

2. We infer which libraries you need based on the file names. The file names are statically analyzable so this should work pretty well as long as the file extensions strongly imply how you will load them. For example we assume that a .csv file will be loaded with FileAttachment.csv and hence needs npm:d3-dsv. I think this would work pretty well, although for SQLite at least there isn’t a strong convention around the file extension. I guess we would assume that .db and .sqlite (and some others) is for SQLite? This could also result in a false positive for example if you load a .csv file as text, but that wouldn’t be terrible.

3. We infer which libraries you need based on the methods you call. But, you can declare a FileAttachment in one place and then call the method in another place, so we can’t simply look for instances of e.g. FileAttachment(name).csv(…). I think this basically means that if you have any member expression of the form object.csv(…) then we have to suppose the object might be a file attachment and hence you need npm:d3-dsv.

I think I’m inclined to take option (2) because it’s the most predictable, and we can just document what our expectations are around file extensions?

[mbostock]

I think I’ll try combining (3) and (2), meaning if you say FileAttachment(name).csv, I’ll assume you need npm:d3-dsv to load a CSV file; but if you just have a bare FileAttachment(name) then I’ll look at the name’s extension to guess what’s needed. With some documentation that should cover 99% of cases and be “good enough”. It’ll be some work to do the static analysis though!

[Fil]

We could build conservatively (sqlite, xlsx, zip), so that no matter how you call these methods the site has everything it needs, but only preload if we statically see FileAttachment().method, since this is only an optimization.

[Fil]

It's very satisfying to build examples/hello-world/ with this branch

[mbostock]

Folded into #843.