https://github.com/moonrepo/espresso

Next-generation JavaScript package registry, package manager, and toolchain.
https://github.com/moonrepo/espresso

Last synced: 3 months ago
JSON representation

Next-generation JavaScript package registry, package manager, and toolchain.

• Host: GitHub
• URL: https://github.com/moonrepo/espresso
• Owner: moonrepo
• License: mit
• Created: 2023-06-26T18:22:20.000Z (over 1 year ago)
• Default Branch: master
• Last Pushed: 2023-10-29T21:26:44.000Z (about 1 year ago)
• Last Synced: 2024-07-27T08:32:57.257Z (4 months ago)
• Language: Rust
• Homepage:
• Size: 909 KB
• Stars: 165
• Watchers: 2
• Forks: 2
• Open Issues: 2
• Metadata Files:
  • Readme: README.md
  • Changelog: CHANGELOG.md
  • Funding: .github/FUNDING.yml
  • License: LICENSE

Awesome Lists containing this project

README

        
# 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.

```toml

[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?