git-publish 0.0.2 → 1.0.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/LICENSE CHANGED
@@ -1,7 +1,21 @@
1
- Copyright (c) 2015 Frank Lyder Bredland
1
+ MIT License
2
2
 
3
- Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
3
+ Copyright (c) Hiroki Osame <hiroki.osame@gmail.com>
4
4
 
5
- The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
6
11
 
7
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
package/README.md ADDED
@@ -0,0 +1,117 @@
1
+ # git-publish
2
+
3
+ Publish your npm package to a Git branch.
4
+
5
+ <sub>Support this project by ⭐️ starring and sharing it. [Follow me](https://github.com/privatenumber) to see what other cool projects I'm working on! ❤️</sub>
6
+
7
+ ## Why?
8
+
9
+ For testing published packages without publishing to npm.
10
+
11
+ Making a prerelease to npm using `npm publish` has the following drawbacks:
12
+
13
+ - Needs a unique version for every release.
14
+
15
+ - Hard to remove due to npm's [strict unpublish policy](https://docs.npmjs.com/policies/unpublish).
16
+
17
+ - Cumbersome to verify the contents of the published package.
18
+
19
+ - Production environment—risky if you make a mistake (eg. accidentally publish as stable).
20
+
21
+ Using `npm link` has the drawback of not running [npm life cycle scripts](https://docs.npmjs.com/cli/v8/using-npm/scripts#life-cycle-scripts) and including non-publishable assets.
22
+
23
+
24
+ In contrast, `git-publish` has the following benefits:
25
+
26
+ - **Unversioned** Instead of versions, branch names are used. Branches can be updated to reflect latest change.
27
+
28
+ - **Deletable** Simply delete the branch when you're done with it.
29
+
30
+ - **Browsable** Use GitHub to verify the contents of the branch. You can even share a link for others to see.
31
+
32
+ - **Dev environment** Low risk of mistakes.
33
+
34
+ - **Simulates `npm publish`** Runs npm life cycle scripts and only includes publishable assets.
35
+
36
+ ## Usage
37
+
38
+ Publish your npm package to a branch on the Git repository:
39
+
40
+ ```sh
41
+ npx git-publish
42
+ ```
43
+
44
+ > **⚠️ Warning:** This command will force-push to the remote branch `npm/<current branch>`. Make sure there are no unsaved changes there.
45
+
46
+
47
+ ### Global install
48
+ Keep the command handy by installing it globally:
49
+
50
+ ```sh
51
+ npm install -g git-publish
52
+ ```
53
+
54
+ When globally installed, you can use it without `npx`:
55
+ ```sh
56
+ git-publish
57
+ ```
58
+
59
+ ### Flags
60
+ | Flag | Description |
61
+ | - | - |
62
+ | `-b, --branch <branch name>` | The branch to publish the package to. Defaults to prefixing "npm/" to the current branch or tag name. |
63
+ | `-r, --remote <remote>` | The remote to push to. (default: `origin`) |
64
+ | `-d, --dry` | Dry run mode. Will not commit or push to the remote. |
65
+ | `-h, --help` | Show help |
66
+ | `--version` | Show version |
67
+
68
+ ## FAQ
69
+
70
+ ### What are some use-cases where this is useful?
71
+ - When you want to test a new package that isn't ready to be published on npm.
72
+
73
+ - 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.
74
+
75
+ - When you want to test in a remote environment so you can't use `npm link`.
76
+
77
+ - When you want to avoid using `npm link` because of symlink complexities.
78
+
79
+
80
+ ### How can I include a build step?
81
+
82
+ 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).
83
+
84
+ ### What does this script do?
85
+
86
+ 1. Run [npm hooks](https://docs.npmjs.com/cli/v8/using-npm/scripts) `prepare` & `prepack`
87
+ 2. Create a temporary branch by prefixing the current branch with the `npm/` namespace
88
+ 3. Detect and commit the [npm publish files](https://github.com/npm/npm-packlist)
89
+ 4. Force push the branch to remote
90
+ 5. Delete local branch from Step 2
91
+ 6. Print the installation command for the branch
92
+
93
+ ### How is this different from simply committing the files to a branch?
94
+
95
+ - 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`.
96
+ - 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.
97
+
98
+ - npm hooks are not executed. _git-publish_ simulates package packing and runs hooks `prepare` and `prepack`.
99
+
100
+ ### Can I publish to and install from a private repository?
101
+
102
+ Yes, if using a Git client authorized to access the private repository.
103
+
104
+ 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.
105
+
106
+
107
+ #### User story
108
+ 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.
109
+
110
+ To work around this, you can publish the branch to _Repo B_ to install it from there:
111
+
112
+ ```sh
113
+ $ npx git-publish --remote git@github.com:repo-b.git --branch test-pkg
114
+
115
+ ✔ Successfully published branch! Install with command:
116
+ → npm i 'repo-b#test-pkg'
117
+ ```