Best practices for non AMD/UMD package

Community Help
8

Hi Owen!

Nice work on AgentScript, agent-based systems are super cool.

To cover a few of these questions:

  • scoped modules: Observable works well with scoped modules - luckily they’re pretty much the same as non-scoped modes expect for the fancy names. For instance, Mike’s notebook about Turf (a project I worked on and rallied for scoped modules) requires from @turf/turf@5, the scoped module path. Scoped modules are good.
  • import operator: This is very fresh, but it’s a part of JavaScript, rather than Observable-specific syntax - and, perhaps confusingly, is an operator instead of a function even though it looks like a function. It’s kind of like new in that way. Because it’s a JavaScript thing and it’s implemented in browsers, it’s another part of Observable that we don’t really mess with - your browser runs the import statement, no transpilation necessary. (pedantic note: import() is a stage-3 proposal to JavaScript, which means it isn’t on MDN docs or part of any spec, but is already being implemented by browsers and is near-guaranteed to eventally be adopted)
  • import syntax: Yeah, the static import syntax doesn’t work (yet), and that’s a bummer - we’re actively talking about how to weigh it against the cross-notebook import syntax, and hope to have a solution that makes import from work for ES modules.
  • Is UMD preferred?: we love UMD and ES modules equally - and I eagerly await the day when everything is ES - but ES modules still have a bunch of kinks to work out:
    • Importing libraries that are built with ES modules right now tends to get you the raw source code: like if I import my simple-statistics module, it’ll load all ~40 files in its src/ directory, in the browser. Which is a bummer for performance - even with HTTP2, loading lots and lots of files is still a drag.
    • Cross-dependencies are hard in both setups, but UMD is pretty clear about being able to require other modules as dependencies of a UMD bundle, whereas setting custom loaders with ES modules is still the wild west.
    • Basically it boils down to ‘JavaScript modules are still super diverse’ so here at Observable Inc we have some opinions about what’s best but also a prerogative to just make the ecosystem of code work roughly as-is, hence the long troubleshooting notebooks :slight_smile:
1 Like