espresso

espresso is a next-generation package registry and package management system for JavaScript, that is not coupled to the current Node.js module and npm systems, and instead is a new paradigm to move the JavaScript ecosystem forward.

THIS PROJECT IS CURRENTLY AN EXPERIMENT AND IS HEAVILY IN DEVELOPMENT! DEFINITELY NOT PRODUCTION READY, AND MAY NEVER REACH FRUITION!

Why a new registry?

The state of Node.js, npm, and the node_modules folder is a complete mess, especially for package owners, but also for package consumers. With the introduction of ESM, the .cjs and .mjs file extensions, the dual-package hazard problem, competition between npm, pnpm, and yarn, and much more, the ecosystem is in a state of chaos. This is further exacerbated by TypeScript, its high number of compiler options, the .cts (.d.cts) and .mts (.d.mts) file extensions, module resolution woes, and other TS features.

The overhead of publishing a package is far too great, and there's no solution in sight. Instead of trying to "fix" the state of things, espresso is a complete reimagining of how everything can work in a modern world.

As a package author

Author your packages in modern ESM. Packages and their source code are published as-is, as packages are compiled on-demand for consumers. No longer are you required to pre-compile packages before publishing, nor fiddle with package.json configuration (especially exports), or worry about deep imports, or the dual-package hazard problem.

As a package consumer

When consuming packages, tailor them to your exact requirements, by requesting all dependencies in a specific compilation target. The days of mismatching module systems and incorrectly compiled packages are over.

[install]
target = "es2016"

Why the name espresso?

espresso is currently a codename until I can think of something better, but there are a few reasons for it. The current binary is named espm, which stands for EcmaScript Package Manager, and since the first 3 letters align with espresso, and JavaScript is already a coffee themed name, it made sense!

But why not simply call it espm? Well, there's more than just a package manager, so using that acronym for other services doesn't make much sense. We could also use esp, or espackage, or something similar, but... branding?