I recommend that libraries publish both a minified UMD bundle and a minified ES module bundle. The UMD bundle provides compatibility with require and CommonJS for legacy environments while the ES module works with modern environments. And I highly recommend Rollup for bundling ES module sources.
The UMD bundle is typically listed as the main entry in the package.json. To target browsers separately from Node, you could consider using the unpkg endpoint. (There’s no apparent agreement on a browser-targeting/AMD-compatible entry field in package.json; the obvious choice of browser is used by Browserify and means something else.)
The ES bundle is listed as the module entry.
It’d be nice if three-orbit-controls were updated to include UMD and ES bundles.
No, that’s actually a better pattern than what I was using. I didn’t realize that Three.js includes the OrbitControls as an example plugin. I’ve updated mine to match Tom’s.
Sorry it’s taken me a while to get back here after initiating this thread. I really want to thank you @mbostock for being persistent and tracking down the root of the problem. Having done so, you explained it quite clearly and offered a few possible resolutions including your proposed code change for more robust module loading as well as moving the json file to a CORS enabled site and avoiding the need for including the CORS proxy altogether. I especially appreciate your gracious response to another alternate approach to including OrbitControls. Your quick and thorough response to issues like this are encouraging for us newbies here on Observable. Thanks again to everyone who contributed to this thread.
P.S. The Notebook Visualizer is a cool tool. Thanks for sharing it too.