monocrate 0.10.0 → 0.11.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.
- package/README.md +6 -6
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -8,7 +8,7 @@ Because publishing from a monorepo should take seconds, not days.
|
|
|
8
8
|
|
|
9
9
|
## The Problem
|
|
10
10
|
|
|
11
|
-
You have a monorepo, you are really proud of `@acme/my-awesome-package` and you want to make it open source.
|
|
11
|
+
You have a monorepo, you are really proud of `@acme/my-awesome-package` and you want to make it open source. The package's main file, `packages/my-awesome-package/src/index.ts`, presumably looks something like this:
|
|
12
12
|
|
|
13
13
|
|
|
14
14
|
```typescript
|
|
@@ -38,7 +38,7 @@ npm notice Publishing to https://registry.npmjs.org/ with tag latest and public
|
|
|
38
38
|
+ @acme/my-awesome-package@1.0.0
|
|
39
39
|
```
|
|
40
40
|
|
|
41
|
-
But
|
|
41
|
+
But when you try to install it, you discover it's broken:
|
|
42
42
|
|
|
43
43
|
```bash
|
|
44
44
|
$ npm install @acme/my-awesome-package
|
|
@@ -48,12 +48,12 @@ npm error 404
|
|
|
48
48
|
npm error 404 '@acme/internal-utils@1.0.0' is not in this registry.
|
|
49
49
|
```
|
|
50
50
|
|
|
51
|
-
This is
|
|
51
|
+
This is a big 🚨 oh-no 🚨 moment. What are your options?
|
|
52
52
|
|
|
53
|
-
In theory, you could
|
|
54
|
-
- ...bundle with esbuild, rollup, and similar tools but tree-shaking breaks for consumers, source maps need a lot of attention to get right, and good luck getting
|
|
53
|
+
In theory, you could:
|
|
54
|
+
- ...bundle with esbuild, rollup, and similar tools but tree-shaking breaks for consumers, source maps need a lot of attention to get right, and good luck getting those TypeScript types (.d.ts files) bundled.
|
|
55
55
|
- ...manually create the right directory structure, replacing all the imports with relative paths. You will manage to pull it off once, but that's definitely not sustainable.
|
|
56
|
-
- ...use a tool such as `lerna` which publishes every internal dependency
|
|
56
|
+
- ...use a tool such as `lerna` which publishes every internal dependency as its own public package, but now `@acme/internal-utils` becomes a permanently published API you're committed to, and your internal refactoring freedom is gone.
|
|
57
57
|
|
|
58
58
|
|
|
59
59
|
## The Solution
|