monocrate 0.12.0 → 0.13.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +8 -13
  2. package/package.json +1 -1
package/README.md CHANGED
@@ -1,24 +1,20 @@
1
1
  # monocrate
2
2
 
3
3
  [![npm version](https://img.shields.io/npm/v/monocrate.svg)](https://www.npmjs.com/package/monocrate)
4
- [![CI](https://github.com/imaman/monocrate/actions/workflows/ci.yml/badge.svg)](https://github.com/imaman/monocrate/actions/workflows/ci.yml)
4
+ [![CI](https://github.com/moojo-tech/monocrate/actions/workflows/ci.yml/badge.svg)](https://github.com/moojo-tech/monocrate/actions/workflows/ci.yml)
5
5
  [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
6
6
 
7
7
  *Monorepos? Great. Publishing from a monorepo? Comically hard.*
8
8
 
9
9
  ## The Problem
10
10
 
11
- Consider `@acme/my-awesome-package`, which imports `@acme/internal-utils`, a workspace dependency. The naive
12
- approach - running `npm publish` - produces an uninstallable package because `@acme/internal-utils` was never published
13
- to npm.
11
+ Consider `@acme/my-awesome-package`, which imports `@acme/internal-utils`, a workspace dependency.
14
12
 
15
- The standard solution is the "publish everything" approach. Tools like [Lerna](https://lerna.js.org/) will publish every
16
- internal dependency as its own public package. Installation now works, but `@acme/internal-utils` just became a
17
- permanently published API you're committed to maintaining. _Your internal refactoring freedom is gone._
13
+ Now you want to publish it.
18
14
 
19
- You can throw a bundler at the problem: tools like [esbuild](https://esbuild.github.io/) or
20
- [Rollup](https://rollupjs.org/) produce a self-contained file from a given entrypoint. But type declarations and
21
- sourcemaps often break, and consumers can't tree-shake a pre-bundled blob.
15
+ - **Naive approach**: `npm publish` produces an uninstallable package - `@acme/internal-utils` was never published.
16
+ - **Publish-all approach** (e.g., [Lerna](https://lerna.js.org/)): Publishes every internal dependency. Now your _internal_ `@acme/internal-utils` is a permanent public API - rename a function there, break consumers you never intended to have.
17
+ - **Bundler approach** (e.g., [esbuild](https://esbuild.github.io/)): Produces a self-contained blob, but types and sourcemaps break, and consumers can't tree-shake.
22
18
 
23
19
  ## The Solution
24
20
 
@@ -30,9 +26,6 @@ produces a standard npm package that looks like you hand-crafted it for publicat
30
26
  - 🔒 Internal packages remain unpublished
31
27
  - ✅ Tree-shaking, sourcemaps, and types all work
32
28
 
33
- > [!NOTE]
34
- > **ESM only** — monocrate supports ES modules exclusively. CommonJS packages (`.cjs` files or `.js` without `"type": "module"`) are not supported. If your monorepo uses CommonJS, consider [migrating to ESM](https://nodejs.org/api/esm.html).
35
-
36
29
  ### Quickstart
37
30
 
38
31
  ```bash
@@ -51,6 +44,8 @@ npx monocrate packages/my-awesome-package --bump patch
51
44
  npx monocrate packages/my-awesome-package --dry-run --output-dir /tmp/inspect --bump patch
52
45
  ```
53
46
 
47
+ > **⚠️ ESM only** — monocrate requires ES modules and rejects CommonJS packages. If your monorepo uses CommonJS, consider [migrating to ESM](https://nodejs.org/api/esm.html) so that you can use monocrate.
48
+
54
49
  ### What Gets Published
55
50
 
56
51
  Given this monorepo structure:
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "monocrate",
3
- "version": "0.12.0",
3
+ "version": "0.13.0",
4
4
  "description": "From monorepo to npm in one command",
5
5
  "type": "module",
6
6
  "main": "dist/src/index.js",