Require error

[tmcw]

Rely on d3-require's special error branch, and switch module entry to source.

[mbostock]

I just shipped d3-require 1.2.0 with RequireError.

[mbostock]

I’m guessing this change isn’t intended?

(It’s here so that unpkg loads the minified ES bundle. It’d be nice if we could have a separate endpoint when consuming the source… but that doesn’t exist yet as far as I’m aware.)

[tmcw]

This was a combination of a yarn/npm bug that I kept running into while working on this branch, and also trying to determine whether we could avoid re-protecting RequireError from terser mangling in every module in the dependency chain from d3-require to the notebook. I think what would capture my intent and yours as well is to specify module: src/index and unpkg: dist/notebook-stdlib. I feel a little icky about the potential of our code depending on pre-bundled and pre-minified dependencies when it could depend on the source.

[mbostock]

The problem is that we want two unpkg-specific entry points but unpkg currently only provides one entry point. We want a minified ES module and a minified UMD:

http://unpkg.com/@observablehq/notebook-stdlib?module
http://unpkg.com/@observablehq/notebook-stdlib

This way, both of these are minified:

import {Library} from "http://unpkg.com/@observablehq/notebook-stdlib?module"

<script src="http://unpkg.com/@observablehq/notebook-stdlib"></script>

There’s an open issue unpkg/unpkg#93 for this, but it doesn’t appear to be moving forward quickly, and even if it were, it’s an unpkg-specific solution which is less than ideal.

It would be possible for us to generate a separate minified ES module that doesn’t use the module entry point, but we’d have to rewrite the bare module specifiers to use relative paths and baked-in semver ranges (exactly what unpkg currently does automatically with ?module).

I think most consumers would be fine with a minified module entry. It’s just an extra pain for us because we have to remember to yarn prepare when editing notebook-stdlib even when it’s yarn link’d into notebook-runtime.

[mbostock]

Alternatively, we could consider not recommending people use ES modules to load our code until unpkg adds built-in support for minifying and rolling-up ES modules. That’d probably be the ideal from our perspective since then the module entry is just the source (but with nonstandard bare module specifiers for external dependencies), but web requests get minified bundles.

[mbostock]

Filed unpkg/unpkg#152.