# Best practices for non AMD/UMD package

**URL:** https://talk.observablehq.com/t/best-practices-for-non-amd-umd-package/259
**Category:** Help
**Created:** [February 7, 2018, 1:08pm UTC](https://talk.observablehq.com/t/best-practices-for-non-amd-umd-package/259 "2018-02-07T13:08:04Z")
**Posts on this page:** 1
**Showing post:** 8

<div class="post-metadata">

### Author: ![tom](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.observablehq.com/tom/32/2262_2.png) [@tom](https://talk.observablehq.com/u/tom)
#### Post date: [February 13, 2018, 6:57pm UTC](https://talk.observablehq.com/t/best-practices-for-non-amd-umd-package/259/8 "2018-02-13T18:57:36Z")

</div>

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](https://beta.observablehq.com/@mbostock/hello-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](https://github.com/tc39/proposal-dynamic-import) - 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 🙂

---

_[View the full topic](https://talk.observablehq.com/t/best-practices-for-non-amd-umd-package/259)._