isolate-package 0.0.0 → 1.0.0-beta.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 +194 -1
- package/package.json +36 -9
- package/dist/index.d.ts +0 -3
- package/dist/index.js +0 -7
package/README.md
CHANGED
|
@@ -1,3 +1,196 @@
|
|
|
1
1
|
# Isolate Package
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Isolate a monorepo workspace package so that it can be deployed as a completely
|
|
4
|
+
self-contained directory with the sources of all local dependencies included.
|
|
5
|
+
|
|
6
|
+
**NOTE**: This package has only been tested with [PNPM](https://pnpm.io/) but it
|
|
7
|
+
was designed to be compatible with NPM and Yarn. That being said, I am
|
|
8
|
+
personally very happy with the switch to PNPM and I encourage anyone to give it
|
|
9
|
+
a try.
|
|
10
|
+
|
|
11
|
+
## Motivation
|
|
12
|
+
|
|
13
|
+
This solution was developed out of a desire to deploy to
|
|
14
|
+
[Firebase](https://firebase.google.com/) from a monorepo without resorting to
|
|
15
|
+
hacks, shell scripts and manual tasks. You can read more about this issue
|
|
16
|
+
[here](#the-problem-with-firebase-in-monorepos).
|
|
17
|
+
|
|
18
|
+
There is nothing Firebase specific to this solution but I am currently not aware
|
|
19
|
+
of any other reason to isolate a workspace package. If you find a different
|
|
20
|
+
use-case, I would love to hear about it.
|
|
21
|
+
|
|
22
|
+
## Features
|
|
23
|
+
|
|
24
|
+
These are the key aspects that set this approach apart from other solutions:
|
|
25
|
+
|
|
26
|
+
- Zero-config for the majority of use-cases. No manual steps involved.
|
|
27
|
+
- Designed to support NPM, Yarn and PNPM workspaces.
|
|
28
|
+
- Compatible with the firebase CLI.
|
|
29
|
+
- Uses a pack/unpack approach to only isolate files that would have been part of
|
|
30
|
+
the published package, so the resulting output only contains the necessary
|
|
31
|
+
files.
|
|
32
|
+
- Isolates dependencies recursively. If package A depends on local package B
|
|
33
|
+
which depends on local package C, all of them will be isolated.
|
|
34
|
+
- Include and adjust the lockfile so you can be sure the isolated deployment is
|
|
35
|
+
using the exact same versions.
|
|
36
|
+
- Optionally include dev dependencies in the isolated output.
|
|
37
|
+
|
|
38
|
+
## Usage
|
|
39
|
+
|
|
40
|
+
Run `pnpm add isolate-package -D` or do the equivalent for `yarn` or `npm`.
|
|
41
|
+
|
|
42
|
+
This package exposes the `isolate` executable. Once installed you can run `npx
|
|
43
|
+
isolate` in any package directory _after_ you have build the source files, and
|
|
44
|
+
by default this will produce a directory at `./isolate`.
|
|
45
|
+
|
|
46
|
+
You will probably want to add the output directory to your `.gitignore` file.
|
|
47
|
+
|
|
48
|
+
### Deploy to Firebase
|
|
49
|
+
|
|
50
|
+
This solution allows you to deploy to Firebase from multiple packages in your
|
|
51
|
+
monorepo, so I advise you to co-locate your `firebase.json` file with the
|
|
52
|
+
package, and not place it in the root of the monorepo.
|
|
53
|
+
|
|
54
|
+
In order to deploy to Firebase, the `functions.source` setting in
|
|
55
|
+
`firebase.json` needs to point to the isolated output folder, which would be
|
|
56
|
+
`./isolate` when using the default configuration.
|
|
57
|
+
|
|
58
|
+
The `predeploy` phase should first build and then isolate the output.
|
|
59
|
+
|
|
60
|
+
Here's an example using [Turborepo](https://turbo.build/) for the build process:
|
|
61
|
+
|
|
62
|
+
```json
|
|
63
|
+
{
|
|
64
|
+
"functions": {
|
|
65
|
+
"source": "./isolate",
|
|
66
|
+
"predeploy": ["turbo build", "isolate"]
|
|
67
|
+
}
|
|
68
|
+
}
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
With this configuration you can run `firebase deploy --only functions` from the
|
|
72
|
+
package you isolated.
|
|
73
|
+
|
|
74
|
+
If you like to deploy to Firebase Functions from multiple packages you will also
|
|
75
|
+
need to configure a unique `codebase` identifier for each of them. For more
|
|
76
|
+
information, [read
|
|
77
|
+
this](https://firebase.google.com/docs/functions/beta/organize-functions).
|
|
78
|
+
|
|
79
|
+
## Configuration
|
|
80
|
+
|
|
81
|
+
For most users the defaults are fine and no configuration is needed. Otherwise,
|
|
82
|
+
you can configure the isolate process by placing a `isolate.config.json` file in
|
|
83
|
+
the root of the package that you want to isolate.
|
|
84
|
+
|
|
85
|
+
Below you find a description of every available config option.
|
|
86
|
+
|
|
87
|
+
### logLevel
|
|
88
|
+
|
|
89
|
+
Type: `"info" | "debug" | "warn" | "error"`, default: `"info"`.
|
|
90
|
+
|
|
91
|
+
Because the configuration loader depends on this setting, its output is not
|
|
92
|
+
affected by this setting. If you want to debug the configuration set
|
|
93
|
+
`ISOLATE_CONFIG_LOG_LEVEL=debug` before you run `isolate`
|
|
94
|
+
|
|
95
|
+
### workspaceRoot
|
|
96
|
+
|
|
97
|
+
Type: `string`, default: `"../.."`
|
|
98
|
+
|
|
99
|
+
The relative path, from the package you want to isolate to the root of the
|
|
100
|
+
workspace / monorepo.
|
|
101
|
+
|
|
102
|
+
In a typical monorepo you will have a `packages` and possibly an `apps`
|
|
103
|
+
directory in the root of the workspace, so any package you want to isolate would
|
|
104
|
+
be 2 levels up from the root.
|
|
105
|
+
|
|
106
|
+
### workspacePackages
|
|
107
|
+
|
|
108
|
+
Type: `string[] | undefined`, default: `undefined`
|
|
109
|
+
|
|
110
|
+
When workspacePackages is not defined, `isolate` will try to find the packages
|
|
111
|
+
in the workspace by looking up the settings in `pnpm-workspace.yaml` or
|
|
112
|
+
`package.json` files depending on the detected package manager.
|
|
113
|
+
|
|
114
|
+
In case this fails, you can override this process by specifying globs manually.
|
|
115
|
+
For example `"workspacePackages": ["packages/*", "apps/*"]`. Paths are relative
|
|
116
|
+
from the root of the workspace.
|
|
117
|
+
|
|
118
|
+
### isolateOutDir
|
|
119
|
+
|
|
120
|
+
Type: `string`, default: `"isolate"`
|
|
121
|
+
|
|
122
|
+
The name of the isolate output directory.
|
|
123
|
+
|
|
124
|
+
### includeDevDependencies
|
|
125
|
+
|
|
126
|
+
Type: `boolean`, default: `false`
|
|
127
|
+
|
|
128
|
+
By default devDependencies are ignored and stripped from the isolated output
|
|
129
|
+
`package.json` files. If you enable this the devDependencies will be included
|
|
130
|
+
and isolated just like the production dependencies.
|
|
131
|
+
|
|
132
|
+
### tsconfigPath
|
|
133
|
+
|
|
134
|
+
Type: `string`, default: `"./tsconfig.json"`
|
|
135
|
+
|
|
136
|
+
The path to the `tsconfig.json` file relative to the package you want to
|
|
137
|
+
isolate. The tsconfig is only used for reading the `compilerOptions.outDir`
|
|
138
|
+
setting. If no tsconfig is found, possibly because you are not using Typescript
|
|
139
|
+
in your project, the process will fall back to the `buildOutputDir` setting.
|
|
140
|
+
|
|
141
|
+
### buildOutputDir
|
|
142
|
+
|
|
143
|
+
Type: `string | undefined`, default: `undefined`
|
|
144
|
+
|
|
145
|
+
When you are not using Typescript you can use this setting to specify where the
|
|
146
|
+
build output files are located.
|
|
147
|
+
|
|
148
|
+
## TODO
|
|
149
|
+
|
|
150
|
+
- [ ] Alter the pnpm lockfile
|
|
151
|
+
- [ ] Add support for Yarn and NPM lock files
|
|
152
|
+
|
|
153
|
+
## Used Terminology
|
|
154
|
+
|
|
155
|
+
The various package managers, while being very similar, seem to use a different
|
|
156
|
+
definition for the term "workspace". If you want to read the code it might be
|
|
157
|
+
good to know that I consider the workspace to be the monorepo itself. The
|
|
158
|
+
overall structure that holds all the packages. Also, in the code you see the
|
|
159
|
+
word manifest a lot. It refers to the contents of a package.json file.
|
|
160
|
+
|
|
161
|
+
## The problem with Firebase in monorepos
|
|
162
|
+
|
|
163
|
+
When deploying to Firebase it expects a folder with source files together with a
|
|
164
|
+
package.json file. This folder will be zipped and uploaded after which Firebase
|
|
165
|
+
will run an npm or yarn install in the cloud as part of the deployment pipeline.
|
|
166
|
+
|
|
167
|
+
In a private monorepo your Firebase package(s) typically have one or more shared
|
|
168
|
+
local dependencies that are never published to NPM. When Firebase tries to look
|
|
169
|
+
up those dependencies from the package.json they can not be found and deployment
|
|
170
|
+
fails.
|
|
171
|
+
|
|
172
|
+
In order to solve this you could try to use a bundler like Webpack to include
|
|
173
|
+
dependencies code in the bundle and then strip those packages from the list in
|
|
174
|
+
the package.json that is sent to Firebase, so doesn't know about them, but this
|
|
175
|
+
strategy quickly falls apart. If the shared packages themselves do not bundle
|
|
176
|
+
all of their dependencies in their build output, then those dependencies will
|
|
177
|
+
still need to be installed, and Firebase wouldn't know about it.
|
|
178
|
+
|
|
179
|
+
Without Firebase natively supporting monorepos, the only solution seems to be to
|
|
180
|
+
bundle each shared workspace dependency in a way that its build output, together
|
|
181
|
+
with its package.json file, becomes part of the overall bundle that is uploaded
|
|
182
|
+
in the Firebase deployment. This way, Firebase can find each shared package
|
|
183
|
+
source code, and also know what dependencies need to be installed to make that
|
|
184
|
+
source code work.
|
|
185
|
+
|
|
186
|
+
There are many different hacks that people have come up with [discussing this
|
|
187
|
+
issue](https://github.com/firebase/firebase-tools/issues/653) but they all seem
|
|
188
|
+
to come down to this:
|
|
189
|
+
|
|
190
|
+
- Copy the shared packages to some deployment folder
|
|
191
|
+
- Create a modified package.json file for the deployment that points all local
|
|
192
|
+
dependencies to the copied files for each shared dependency.
|
|
193
|
+
- Point the Firebase deploy process to that folder
|
|
194
|
+
|
|
195
|
+
The `isolate` process from this solution takes a similar approach but is more
|
|
196
|
+
sophisticated and hides all complexity from the user.
|
package/package.json
CHANGED
|
@@ -1,20 +1,47 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "isolate-package",
|
|
3
|
-
"version": "0.0.0",
|
|
4
|
-
"description": "
|
|
5
|
-
"
|
|
6
|
-
"
|
|
3
|
+
"version": "1.0.0-beta.0",
|
|
4
|
+
"description": "Isolate a monorepo package by bundling the build output with its shared workspace packages and lock file to form a self-contained directory.",
|
|
5
|
+
"author": "Thijs Koerselman",
|
|
6
|
+
"license": "MIT",
|
|
7
|
+
"keywords": [
|
|
8
|
+
"monorepo",
|
|
9
|
+
"workspace",
|
|
10
|
+
"isolate",
|
|
11
|
+
"package",
|
|
12
|
+
"deploy",
|
|
13
|
+
"firebase",
|
|
14
|
+
"ci",
|
|
15
|
+
"pnpm",
|
|
16
|
+
"yarn",
|
|
17
|
+
"npm"
|
|
18
|
+
],
|
|
7
19
|
"type": "module",
|
|
20
|
+
"module": "dist/index.js",
|
|
8
21
|
"files": [
|
|
9
22
|
"dist"
|
|
10
23
|
],
|
|
11
|
-
"
|
|
12
|
-
|
|
24
|
+
"bin": {
|
|
25
|
+
"isolate": "dist/index.js"
|
|
26
|
+
},
|
|
27
|
+
"dependencies": {
|
|
28
|
+
"chalk": "^5.2.0",
|
|
29
|
+
"fs-extra": "^11.1.1",
|
|
30
|
+
"glob": "^10.2.2",
|
|
31
|
+
"lodash-es": "^4.17.21",
|
|
32
|
+
"source-map-support": "^0.5.21",
|
|
33
|
+
"tar-fs": "^2.1.1",
|
|
34
|
+
"yaml": "^2.2.2"
|
|
35
|
+
},
|
|
13
36
|
"devDependencies": {
|
|
14
|
-
"@types/
|
|
37
|
+
"@types/fs-extra": "^11.0.1",
|
|
38
|
+
"@types/lodash-es": "^4.17.7",
|
|
39
|
+
"@types/node": "^18.16.2",
|
|
40
|
+
"@types/source-map-support": "^0.5.6",
|
|
41
|
+
"@types/tar-fs": "^2.0.1",
|
|
15
42
|
"tsup": "^6.7.0",
|
|
16
|
-
"
|
|
17
|
-
"vitest": "^0.
|
|
43
|
+
"type-fest": "^3.9.0",
|
|
44
|
+
"vitest": "^0.30.1"
|
|
18
45
|
},
|
|
19
46
|
"scripts": {
|
|
20
47
|
"build": "tsup-node",
|
package/dist/index.d.ts
DELETED