git-publish 2.1.0 → 2.2.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 +88 -64
- package/dist/index.js +66 -66
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
# git-publish
|
|
2
2
|
|
|
3
|
-
Publish your npm package to a Git branch.
|
|
3
|
+
Publish your npm package to a Git branch.
|
|
4
|
+
Useful for testing packages in production-like environments before publishing to npm.
|
|
4
5
|
|
|
5
6
|
<br>
|
|
6
7
|
|
|
@@ -11,122 +12,145 @@ Publish your npm package to a Git branch. Great for pre-publishing a package for
|
|
|
11
12
|
|
|
12
13
|
## Why?
|
|
13
14
|
|
|
14
|
-
To test a package without publishing to npm.
|
|
15
|
+
To test a package without publishing to the npm registry.
|
|
15
16
|
|
|
16
|
-
|
|
17
|
+
### Why not use `npm publish`?
|
|
17
18
|
|
|
18
|
-
|
|
19
|
+
Publishing to npm just for testing has major downsides:
|
|
19
20
|
|
|
20
|
-
- **Versioning
|
|
21
|
-
- **
|
|
22
|
-
- **
|
|
23
|
-
- **Risky:**
|
|
21
|
+
- **Versioning overhead:** You must bump the version, even for throwaway builds.
|
|
22
|
+
- **Permanent:** npm's [strict unpublish policy](https://docs.npmjs.com/policies/unpublish) makes removing test releases difficult.
|
|
23
|
+
- **Hard to inspect:** npm doesn't make it easy to view the contents of a published package.
|
|
24
|
+
- **Risky:** You could accidentally publish test code as a stable release.
|
|
24
25
|
|
|
25
|
-
|
|
26
|
-
- No [npm life cycle scripts](https://docs.npmjs.com/cli/v8/using-npm/scripts#life-cycle-scripts)
|
|
27
|
-
- Includes non-publishable assets
|
|
28
|
-
- Doesn't install dependencies
|
|
26
|
+
### Why not use `npm link`?
|
|
29
27
|
|
|
28
|
+
- Skips [npm lifecycle scripts](https://docs.npmjs.com/cli/v8/using-npm/scripts#life-cycle-scripts)
|
|
29
|
+
- Links the entire project (including source, tests, configs)
|
|
30
|
+
- Doesn't install dependencies automatically
|
|
30
31
|
|
|
31
|
-
|
|
32
|
+
### So why `git-publish`?
|
|
32
33
|
|
|
33
|
-
- **No
|
|
34
|
-
|
|
35
|
-
- **
|
|
36
|
-
|
|
37
|
-
- **
|
|
38
|
-
|
|
39
|
-
- **Dev environment:** Low risk of mistakes.
|
|
40
|
-
|
|
41
|
-
- **Simulates `npm publish`:** Runs npm life cycle scripts and only includes publishable assets.
|
|
34
|
+
- **No versioning required:** Uses Git branches instead of package versions.
|
|
35
|
+
- **Easy cleanup:** Delete the branch when you're done.
|
|
36
|
+
- **Browsable:** View and verify the published package on GitHub.
|
|
37
|
+
- **Safe:** Keeps test builds out of npm.
|
|
38
|
+
- **Realistic simulation:** Runs `prepare` and `prepack`, and includes only publishable files.
|
|
42
39
|
|
|
43
40
|
## Usage
|
|
44
41
|
|
|
45
|
-
Publish your npm package to a
|
|
42
|
+
Publish your npm package to a Git branch:
|
|
46
43
|
|
|
47
44
|
```sh
|
|
48
45
|
npx git-publish
|
|
49
46
|
```
|
|
50
47
|
|
|
51
|
-
This
|
|
52
|
-
|
|
48
|
+
This publishes the current package to the branch `npm/<current branch>` on the remote `origin`.
|
|
53
49
|
|
|
54
50
|
### Global install
|
|
55
|
-
Keep the command handy by installing it globally:
|
|
56
51
|
|
|
57
52
|
```sh
|
|
58
53
|
npm install -g git-publish
|
|
59
54
|
```
|
|
60
55
|
|
|
61
|
-
|
|
56
|
+
Then run with:
|
|
57
|
+
|
|
62
58
|
```sh
|
|
63
59
|
git-publish
|
|
64
60
|
```
|
|
65
61
|
|
|
66
|
-
### Flags
|
|
67
|
-
|
|
68
|
-
|
|
|
69
|
-
|
|
|
70
|
-
| `-
|
|
71
|
-
| `-
|
|
72
|
-
| `-
|
|
73
|
-
| `-
|
|
74
|
-
|
|
|
62
|
+
### CLI Flags
|
|
63
|
+
|
|
64
|
+
| Flag | Description |
|
|
65
|
+
| ----------------------- | ------------------------------------------------------------- |
|
|
66
|
+
| `-b, --branch <name>` | Target branch name. Defaults to `npm/<current branch or tag>` |
|
|
67
|
+
| `-r, --remote <remote>` | Git remote to push to (default: `origin`) |
|
|
68
|
+
| `-o, --fresh` | Create a fresh single-commit branch. Force-pushes to remote |
|
|
69
|
+
| `-d, --dry` | Simulate the process. Does not commit or push |
|
|
70
|
+
| `-h, --help` | Show CLI help |
|
|
71
|
+
| `--version` | Show CLI version |
|
|
75
72
|
|
|
76
73
|
## FAQ
|
|
77
74
|
|
|
78
|
-
### What are some use
|
|
79
|
-
- When you want to test a new package that isn't ready to be published on npm.
|
|
75
|
+
### What are some use cases?
|
|
80
76
|
|
|
81
|
-
-
|
|
77
|
+
- Testing a package before it's ready for npm
|
|
78
|
+
- Contributing to a repo where you don't have publish access
|
|
79
|
+
- Testing in a CI/CD or remote environment where `npm link` doesn't work
|
|
80
|
+
- Avoiding symlink issues from `npm link`
|
|
82
81
|
|
|
83
|
-
|
|
82
|
+
### How do I include a build step?
|
|
84
83
|
|
|
85
|
-
|
|
84
|
+
Add your build command to the [`prepack`](https://docs.npmjs.com/cli/v8/using-npm/scripts#prepack) script in `package.json`:
|
|
86
85
|
|
|
86
|
+
```json5
|
|
87
|
+
{
|
|
88
|
+
// ...
|
|
89
|
+
|
|
90
|
+
"scripts": {
|
|
91
|
+
"prepack": "npm run build",
|
|
92
|
+
},
|
|
93
|
+
}
|
|
94
|
+
```
|
|
87
95
|
|
|
88
|
-
|
|
96
|
+
This mirrors the same behavior as `npm publish`.
|
|
89
97
|
|
|
90
|
-
|
|
98
|
+
### What does `git-publish` do?
|
|
91
99
|
|
|
92
|
-
|
|
100
|
+
1. Checks out or creates the publish branch
|
|
101
|
+
2. Runs the `prepare` and `prepack` npm scripts
|
|
102
|
+
3. Uses [npm-packlist](https://github.com/npm/npm-packlist) to determine publishable files
|
|
103
|
+
4. Commits only those files
|
|
104
|
+
5. Pushes the branch to the Git remote
|
|
105
|
+
6. Prints the command to install the package via Git
|
|
93
106
|
|
|
94
|
-
|
|
95
|
-
2. Run [npm hooks](https://docs.npmjs.com/cli/v8/using-npm/scripts) `prepare` & `prepack`
|
|
96
|
-
3. Detect and commit only the [npm publish files](https://github.com/npm/npm-packlist)
|
|
97
|
-
4. Push the branch to remote
|
|
98
|
-
6. Print the installation command for the branch
|
|
107
|
+
### Why preserve commit history on the publish branch?
|
|
99
108
|
|
|
100
|
-
|
|
109
|
+
When installing from Git, npm uses commit hashes—not branch names. If the commit is "detached" (i.e., unreachable from history), it may be garbage-collected, breaking installs.
|
|
101
110
|
|
|
102
|
-
|
|
111
|
+
To avoid this, `git-publish` preserves history by default.
|
|
103
112
|
|
|
104
|
-
|
|
113
|
+
If you prefer a single clean commit and understand the risks, use the `--fresh` flag to force-push a one-commit branch.
|
|
105
114
|
|
|
106
|
-
|
|
115
|
+
### Why not just commit the files manually?
|
|
107
116
|
|
|
108
|
-
|
|
117
|
+
Manual commits often:
|
|
109
118
|
|
|
110
|
-
-
|
|
111
|
-
-
|
|
119
|
+
- Miss important files (e.g., those not in `dist/`)
|
|
120
|
+
- Include irrelevant files (e.g., tests, source, configs)
|
|
121
|
+
- Skip npm lifecycle scripts
|
|
112
122
|
|
|
113
|
-
-
|
|
123
|
+
`git-publish` avoids these pitfalls by using `npm-packlist` (same as `npm publish`) and running `prepare` and `prepack`.
|
|
124
|
+
|
|
125
|
+
### Can I use this in a monorepo?
|
|
126
|
+
|
|
127
|
+
Yes. Run `git-publish` from inside the specific package directory (e.g., `packages/my-lib`).
|
|
128
|
+
|
|
129
|
+
It will detect and publish only that package's contents to the root of the Git branch.
|
|
130
|
+
|
|
131
|
+
> [!IMPORTANT]
|
|
132
|
+
> Currently does not support resolving `workspace:` protocol dependencies. Avoid using those or pre-bundle them before publishing.
|
|
114
133
|
|
|
115
134
|
### Can I publish to and install from a private repository?
|
|
116
135
|
|
|
117
|
-
Yes
|
|
136
|
+
Yes—if your Git client (e.g., local dev, CI, etc.) is authorized to access the repo.
|
|
118
137
|
|
|
119
|
-
If
|
|
138
|
+
If that's not possible, you can push the branch to a public repo using the `--remote` flag.
|
|
120
139
|
|
|
140
|
+
> [!WARNING]
|
|
141
|
+
> Minify or obfuscate private code before publishing to a public repo.
|
|
121
142
|
|
|
122
|
-
####
|
|
123
|
-
You want to test a branch on a private repository _Repo A_, but GitHub Actions on the consuming project _Repo B_ doesn't have access to the private repository so `npm install` fails.
|
|
143
|
+
#### Example: publishing from private repo A to public repo B
|
|
124
144
|
|
|
125
|
-
|
|
145
|
+
Say you're testing changes in **Repo A**, but your GitHub Actions workflow in **Repo B** can't access private repos. You can push the publish branch to **Repo B** instead:
|
|
126
146
|
|
|
127
147
|
```sh
|
|
128
|
-
|
|
148
|
+
npx git-publish --remote git@github.com:repo-b.git --branch test-pkg
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
Result:
|
|
129
152
|
|
|
153
|
+
```sh
|
|
130
154
|
✔ Successfully published branch! Install with command:
|
|
131
155
|
→ npm i 'repo-b#test-pkg'
|
|
132
156
|
```
|
|
@@ -137,4 +161,4 @@ $ npx git-publish --remote git@github.com:repo-b.git --branch test-pkg
|
|
|
137
161
|
<a href="https://github.com/sponsors/privatenumber">
|
|
138
162
|
<img src="https://cdn.jsdelivr.net/gh/privatenumber/sponsors/sponsorkit/sponsors.svg">
|
|
139
163
|
</a>
|
|
140
|
-
</p>
|
|
164
|
+
</p>
|