Publishing in JavaScript Ecosystem: How to Keep Everyone Happy?
summary
Recommends shipping an ES module first but also a CommonJS build using conditional exports, generated from one TypeScript source so both node and bundlers work; use dnt for Deno and verify Cloudflare Workers run your webpacked bundle. Trim publish/install size with package.json "files" and minimal dependencies, offer a debug variant (dist tag) with source maps, and publish TypeScript declarations (or submit to DefinitelyTyped) — types prevent ~15–38% of bugs. Provide observability via an external OpenTelemetry instrumentation package.
AI-written summary · about
chapters (17)
- 0:00Intro
- 1:04Why talk about publishing?
- 2:32What are we going to cover?
- 3:07Which criteria will affect you?
- 4:00Publishing Criteria
- 5:52Criteria: Server (why?)
- 8:34Criteria: JS Native (why?)
- 9:50Criteria: Module Formats why
- 12:59Criteria: Sizes (why?)
- 14:08Criteria: Reduce Publish Size h
- 15:09Criteria: Reduce Install Size ho
- 15:41Criteria: Reduce Bundle Size ho
- 16:32Criteria: Types (why?)
- 18:28Criteria: Debugging (why?)
- 20:07Criteria: Observability why?
- 21:42Conclusion (opinionated)
- 22:50Thank you for listening
related talks
24mPublishing in the JavaScript Ecosystem & Keeping Users Happy
34mTowards a simpler JavaScript ecosystem
24mThe Complete Guide to packaging Libraries
46mThe “Perfect” JS Library Tooling
30mTowards a simpler JavaScript ecosystem
15mWrite once, run anywhere - cross-env JS
58m10KB or Bust: The Delicate Power of Webpack and Babel
34mGift Wrap Your Code with Webpack