search

observablehq / framework

A static site generator for data apps, dashboards, reports, and more. Observable Framework combines JavaScript on the front-end for interactive graphics with any language on the back-end for data analysis.
https://observablehq.com/framework/
ISC License
2.57k stars 123 forks source link

use observablehq:stdlib instead of npm:@observablehq/stdlib #1670

Closed mbostock closed 2 months ago

mbostock commented 2 months ago

The goal here is to differentiate packages that are built-in to Framework from ones that are published and loaded from npm. This PR only makes this change for the standard library (observablehq:stdlib), but if other built-in modules are provided in the future, we could use observablehq: for that, too.

Note that there are several other libraries such as npm:@observablehq/dot that we intend to publish to npm in the future, but for pragmatism are currently implemented as built-ins. We don’t want to switch these to observablehq: because the desired future state is for these libraries to be published to and imported from npm rather than being built-in.

Also some libraries as npm:@observablehq/xlsx and npm:@observablehq/zip should be private built-ins as these are not intended to be published to npm nor imported directly; they are only intended to be used by FileAttachment and are imported as observablehq:stdlib/xlsx and observablehq:stdlib/zip.

Related #852.

mbostock commented 2 months ago

Should I expand this to include other built-in libraries @Fil? Basically anything that I don’t think is really worth it to publish as a standalone library to npm? (We could always publish it to npm in the future if there’s demand to use a library outside of Framework, but most of these are pretty trivial…)

And should I add an “Observable imports” section to the Imports documentation that describes the observablehq: protocol?

Fil commented 2 months ago

Yes it would be good to clarify all of this. Doesn't seem blocking for this PR though.

mbostock commented 2 months ago

I sketched out what it would look like to use e.g. observablehq:stdlib/sqlite instead of npm:@observablehq/sqlite, and it feels like the more we embrace observablehq:, the higher risk of confusion since we need to explain the protocol. Maybe we should stick with the original plan and try to publish these to npm and favor decoupling when possible. Though I think it seems reasonable for observablehq:stdlib to still be a built-in since it is tightly coupled with Framework (e.g. view depends on Generators.input). Hmm. 🤔

mbostock commented 2 months ago

TODO Add documentation for observablehq: imports.