propagate-cli 1.11.5 → 1.11.7
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 +15 -28
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -2,7 +2,9 @@
|
|
|
2
2
|
|
|
3
3
|
Propagate updated packages throughout a project.
|
|
4
4
|
|
|
5
|
-
Managing dependencies can be
|
|
5
|
+
Managing dependencies can be tiresome if your project relies on more than a few frequently updated packages.
|
|
6
|
+
Consider the following dependency graph.
|
|
7
|
+
Here the solid lines represent dependencies, the dotted lines developer dependencies:
|
|
6
8
|
|
|
7
9
|
---
|
|
8
10
|
alice
|
|
@@ -25,11 +27,15 @@ Managing dependencies can be irksome if your project relies on more than a few f
|
|
|
25
27
|
| .
|
|
26
28
|
freddie
|
|
27
29
|
---
|
|
28
|
-
|
|
30
|
+
If we fix a bug in the `freddie` package and bump its patch number then we must update the package JSON files of both the `erica` and `chuck` packages in order to make sure that they both make use of the updated `freddie` package.
|
|
31
|
+
However, that is not the end of the task.
|
|
32
|
+
We must also bump their package numbers and update the package JSON files of packages or binaries that depend on them, too.
|
|
33
|
+
And so on, ad nauseam.
|
|
29
34
|
|
|
30
|
-
|
|
35
|
+
Propagate automates the process, allowing you to update the `version`, `dependencies` and `devDependencies` fields of all the requisite package JSON files in a project whenever a package is updated, effectively propagating the original update through the entire project.
|
|
36
|
+
It will also optionally save, commit and publish these changes by way of configurable shell commands.
|
|
31
37
|
|
|
32
|
-
|
|
38
|
+
Here are the actual updates that Propagate would make:
|
|
33
39
|
|
|
34
40
|
```
|
|
35
41
|
'./freddie' ("freddie"):
|
|
@@ -59,7 +65,10 @@ Managing dependencies can be irksome if your project relies on more than a few f
|
|
|
59
65
|
"bernard": "^1.3.2" -> "^1.3.3",
|
|
60
66
|
}
|
|
61
67
|
```
|
|
62
|
-
Note that only core [semver](https://semver.org/) versions are supported, that is, versions of the form `major.minor.patch` where `major`, `minor` and `patch` are natural numbers.
|
|
68
|
+
Note that only core [semver](https://semver.org/) versions are supported, that is, versions of the form `major.minor.patch` where `major`, `minor` and `patch` are natural numbers.
|
|
69
|
+
As yet Propagate does not support version ranges or multiple sets.
|
|
70
|
+
Additionally, it will leave intact but otherwise ignore modifiers such as `^` and `~`.
|
|
71
|
+
If you are not using either just these modifiers or no modifiers at all, Propagate is unlikely to work for you.
|
|
63
72
|
|
|
64
73
|
## Installation
|
|
65
74
|
|
|
@@ -98,7 +107,7 @@ Commands:
|
|
|
98
107
|
|
|
99
108
|
list-directories List directories, including the default directory
|
|
100
109
|
|
|
101
|
-
set-shell-commands Set the Git, build, install and publish shell commands
|
|
110
|
+
set-shell-commands Set the Git, poll, build, install and publish shell commands
|
|
102
111
|
|
|
103
112
|
add-ignored-dependency Add an ignored dependency
|
|
104
113
|
|
|
@@ -135,28 +144,6 @@ To propagate the `freddie` package, for example, run the following command:
|
|
|
135
144
|
|
|
136
145
|
You can also execute a lone `propagate` command from within a package's subdirectory and it will propagate that package.
|
|
137
146
|
|
|
138
|
-
Here are some things to bear in mind:
|
|
139
|
-
|
|
140
|
-
1. It is recommended that you initially use the `dry-run` option, which will list the updates without making any changes. Also, you should always use the `yes` and `quietly` options with caution.
|
|
141
|
-
|
|
142
|
-
2. Propagate creates separate directed graphs for the dependencies and the developer dependencies. If there are cycles present in either graph, it will terminate and report one of the cycles. If there are cycles present in the combined graph, however, these are tolerated because they are justifiable in practice.
|
|
143
|
-
|
|
144
|
-
3. Updates are applied in a topological order of the dependencies with the initially propagated package updated first. What this means in practice is that dependencies are guaranteed to be updated before their dependents. Therefore, if you chose not to update a particular dependency or chose to terminate the update process altogether, usually no problems will result. However, bear in mind the following point.
|
|
145
|
-
|
|
146
|
-
4. It is possible, because of the aforementioned tolerance of cycles in the combined graph, that cases may arise where updates are applied that reference developer dependencies that have themselves yet to be updated. In these cases, Propagate will terminate before the propagation has even started and will tell you about the problem. There is little choice but to terminate prematurely in these cases because continuing with the propagation, even with careful user intervention, will almost certainly result in failure. The solution in these cases, which will be suggested by Propagate, is to add a forced dependency relation between the offending developer dependency and its dependent. Propagate does not alter the `package.json` files themselves, but pretends as if they were, adding a standard dependency relation as opposed to a developer dependency relation between the two, thus forcing the developer dependency to come first in the propagation. This itself may result in a cycle, of course, in which case you will have no alternative but to re-think your dependency structure.
|
|
147
|
-
|
|
148
|
-
It is important to understand what happens when you choose to answer 'no' to any of the prompts.
|
|
149
|
-
|
|
150
|
-
1. If you chose to answer 'no' at a save prompt, Propagate will assume that you do not want to propagate the package and will adjust all the remaining updates accordingly.
|
|
151
|
-
|
|
152
|
-
2. If you chose to answer 'no' at either a build prompt or an install prompt, Propagate will continue with the update. The rationale behind this is that the update in question might not be to a package but instead to a project that may need its `package.json` file updated with the latest dependencies but may not need to be built right away. Also bear in mind that you do not need to rebuild a package before publishing if all you are doing is updating its dependencies. Therefore you can safely answer 'no' at either of these prompts even for propagated packages.
|
|
153
|
-
|
|
154
|
-
3. If you choose to answer 'no' at a Git prompt, much the same rationale as for installing and building holds.
|
|
155
|
-
|
|
156
|
-
4. If you choose to answer 'no' at a publish prompt, Propagate will again assume that you do not want to propagate the package and will make the necessary adjustments as before.
|
|
157
|
-
|
|
158
|
-
It is worth repeating that if you decide to terminate the update process entirely, do so by answering 'no' three times at any prompt in order to give Propagate the chance to exit gracefully and appraise you of any problems with developer dependencies.
|
|
159
|
-
|
|
160
147
|
## Contact
|
|
161
148
|
|
|
162
149
|
* james.smith@djalbat.com
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "propagate-cli",
|
|
3
3
|
"author": "James Smith",
|
|
4
|
-
"version": "1.11.
|
|
4
|
+
"version": "1.11.7",
|
|
5
5
|
"license": "MIT, Anti-996",
|
|
6
6
|
"homepage": "https://github.com/djalbat/propagate-cli",
|
|
7
7
|
"description": "Propagate updated packages throughout a project.",
|
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
},
|
|
15
15
|
"dependencies": {
|
|
16
16
|
"argumentative": "^2.0.36",
|
|
17
|
-
"necessary": "^
|
|
17
|
+
"necessary": "^17.0.1",
|
|
18
18
|
"occam-directed-graphs": "^3.0.79"
|
|
19
19
|
},
|
|
20
20
|
"devDependencies": {
|