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.
Files changed (3) hide show
  1. package/README.md +88 -64
  2. package/dist/index.js +66 -66
  3. 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. Great for pre-publishing a package for testing.
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
- #### Why not use `npm publish` to make a pre-release?
17
+ ### Why not use `npm publish`?
17
18
 
18
- Because of the following drawbacks:
19
+ Publishing to npm just for testing has major downsides:
19
20
 
20
- - **Versioning concerns:** even though you're just testing, you still need to version bump
21
- - **Undeleteable:** releases are hard to remove due to npm's [strict unpublish policy](https://docs.npmjs.com/policies/unpublish)
22
- - **Unverifyable:** npm does not offer a great way to browse the contents of a package
23
- - **Risky:** Publishing tests to a production environment can be dangerous (eg. accidentally publish as stable)
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
- #### What about `npm link`?
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
- #### So why `git-publish`?
32
+ ### So why `git-publish`?
32
33
 
33
- - **No versions:** Instead of versions, branch names are used. Branches can be updated to reflect latest change.
34
-
35
- - **Deletable:** Simply delete the branch when you're done with it.
36
-
37
- - **Browsable:** Use GitHub to easily verify the contents of the branch. You can even share a link for others to see.
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 branch on the Git repository:
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 command will publish to the remote branch `npm/<current branch>`.
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
- When globally installed, you can use it without `npx`:
56
+ Then run with:
57
+
62
58
  ```sh
63
59
  git-publish
64
60
  ```
65
61
 
66
- ### Flags
67
- | Flag | Description |
68
- | - | - |
69
- | `-b, --branch <branch name>` | The branch to publish the package to. Defaults to prefixing "npm/" to the current branch or tag name. |
70
- | `-r, --remote <remote>` | The remote to push to. (default: `origin`) |
71
- | `-o, --fresh` | Publish without a commit history. Warning: Force-pushes to remote |
72
- | `-d, --dry` | Dry run mode. Will not commit or push to the remote. |
73
- | `-h, --help` | Show help |
74
- | `--version` | Show version |
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-cases where this is useful?
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
- - When you're contributing to an open source project so you don't have publish access, but want to test the changes in a production-like environment.
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
- - When you want to test in a remote environment so you can't use `npm link`.
82
+ ### How do I include a build step?
84
83
 
85
- - When you want to avoid using `npm link` because of symlink complexities.
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
- ### How can I include a build step?
96
+ This mirrors the same behavior as `npm publish`.
89
97
 
90
- Like `npm publish`, you can call the build command it in the [`prepack` script](https://docs.npmjs.com/cli/v8/using-npm/scripts#:~:text=on%20npm%20publish.-,prepack,-Runs%20BEFORE%20a).
98
+ ### What does `git-publish` do?
91
99
 
92
- ### What does this script do?
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
- 1. If publish branch exists on remote, check it out to apply changes on top. Otherwise, create a new branch.
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
- ### Why is the commit history preserved in the publish branch?
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
- When pushing an npm installable commit to Git, it's important that it's an attached commit.
111
+ To avoid this, `git-publish` preserves history by default.
103
112
 
104
- This is because npm lock references the commit hash, and not the branch name. So if the commit is detached, it will be removed upon reference loss and any subsequent npm installations referencing that commit hash will fail.
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
- If you'd like a publish branch with a clean commit history despite these drawbacks, you can use the `--fresh` flag to force-push a single-commit branch to the remote.
115
+ ### Why not just commit the files manually?
107
116
 
108
- ### How is this different from simply committing the files to a branch?
117
+ Manual commits often:
109
118
 
110
- - There can be missing distribution files (eg. files outside of `dist`). _git-publish_ uses [npm-packlist](https://github.com/npm/npm-packlist) —the same library `npm publish` uses—to detect publish files declared via `package.json#files` and `.npmignore`.
111
- - Irrelevant files are committed (eg. source files). This can slow down installation or even interfere with the library behavior. For example, if your project has development configuration files, they can accidentally be read by the dependent tooling.
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
- - npm hooks are not executed. _git-publish_ simulates package packing and runs hooks `prepare` and `prepack`.
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, if using a Git client authorized to access the private repository.
136
+ Yesif your Git client (e.g., local dev, CI, etc.) is authorized to access the repo.
118
137
 
119
- If it must be publicly accessible, you can set the `--remote <remote>` flag to push the publish assets to a public repository. It's recommended to compile and minify the code if doing this with private code.
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
- #### User story
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
- To work around this, you can publish the branch to _Repo B_ to install it from there:
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
- $ npx git-publish --remote git@github.com:repo-b.git --branch test-pkg
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>