@itrocks/dependency 0.0.5 → 0.0.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 +139 -0
- package/cjs/dependency.js +1 -1
- package/package.json +5 -3
package/README.md
CHANGED
|
@@ -7,3 +7,142 @@
|
|
|
7
7
|
# dependency
|
|
8
8
|
|
|
9
9
|
Builds a dependency-sorted list of Nodes.js modules.
|
|
10
|
+
|
|
11
|
+
*This documentation was written by an artificial intelligence and may contain errors or approximations.
|
|
12
|
+
It has not yet been fully reviewed by a human. If anything seems unclear or incomplete,
|
|
13
|
+
please feel free to contact the author of this package.*
|
|
14
|
+
|
|
15
|
+
## Installation
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
npm i @itrocks/dependency
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
This package is meant to be used in a Node.js environment. It scans the
|
|
22
|
+
installed modules starting from a given directory and returns their names
|
|
23
|
+
ordered so that every package appears **after** all its dependencies.
|
|
24
|
+
|
|
25
|
+
## Usage
|
|
26
|
+
|
|
27
|
+
`@itrocks/dependency` exposes a single async helper: `dependencies`.
|
|
28
|
+
|
|
29
|
+
It inspects the installed packages (those visible from the given
|
|
30
|
+
directory) and builds a list of package names sorted in dependency order.
|
|
31
|
+
If a cyclic dependency is detected, the function rejects with an error
|
|
32
|
+
describing the cycle.
|
|
33
|
+
|
|
34
|
+
By default, it starts from the application directory detected by
|
|
35
|
+
`@itrocks/app-dir`, so in many cases you can simply call it without
|
|
36
|
+
arguments.
|
|
37
|
+
|
|
38
|
+
### Minimal example
|
|
39
|
+
|
|
40
|
+
```ts
|
|
41
|
+
import { dependencies } from '@itrocks/dependency'
|
|
42
|
+
|
|
43
|
+
async function main ()
|
|
44
|
+
{
|
|
45
|
+
const ordered = await dependencies()
|
|
46
|
+
|
|
47
|
+
console.log('Packages in dependency order:')
|
|
48
|
+
for (const name of ordered) {
|
|
49
|
+
console.log(' -', name)
|
|
50
|
+
}
|
|
51
|
+
}
|
|
52
|
+
|
|
53
|
+
main().catch((error) => {
|
|
54
|
+
console.error('Unable to compute dependencies:', error)
|
|
55
|
+
process.exitCode = 1
|
|
56
|
+
})
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
### Complete example – running tasks in dependency order
|
|
60
|
+
|
|
61
|
+
The typical use‑case is to perform some work (build, migration,
|
|
62
|
+
initialisation, checks, …) module by module, while ensuring that each
|
|
63
|
+
module is processed **after** all the modules it depends on.
|
|
64
|
+
|
|
65
|
+
```ts
|
|
66
|
+
import { dependencies } from '@itrocks/dependency'
|
|
67
|
+
import { spawn } from 'node:child_process'
|
|
68
|
+
import { promisify } from 'node:util'
|
|
69
|
+
|
|
70
|
+
const spawnAsync = promisify(spawn)
|
|
71
|
+
|
|
72
|
+
async function runBuildsInOrder ()
|
|
73
|
+
{
|
|
74
|
+
// Compute the list of installed packages in dependency order
|
|
75
|
+
const ordered = await dependencies() // starts from your app directory
|
|
76
|
+
|
|
77
|
+
for (const pkg of ordered) {
|
|
78
|
+
// Here we arbitrarily decide to run an npm script on each package.
|
|
79
|
+
// You could instead require a file, run database migrations, etc.
|
|
80
|
+
console.log('Building', pkg)
|
|
81
|
+
await spawnAsync('npm', ['run', 'build', '--workspace', pkg], {
|
|
82
|
+
stdio: 'inherit',
|
|
83
|
+
})
|
|
84
|
+
}
|
|
85
|
+
}
|
|
86
|
+
|
|
87
|
+
runBuildsInOrder().catch((error) => {
|
|
88
|
+
console.error('Build aborted because of dependency issue:', error)
|
|
89
|
+
process.exitCode = 1
|
|
90
|
+
})
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
In the example above, `@itrocks/dependency` is responsible only for the
|
|
94
|
+
ordering. What you actually do with each package (`npm run build`,
|
|
95
|
+
custom scripts, migrations, checks, …) is entirely up to your
|
|
96
|
+
application.
|
|
97
|
+
|
|
98
|
+
## API
|
|
99
|
+
|
|
100
|
+
### `dependencies(path?: string): Promise<string[]>`
|
|
101
|
+
|
|
102
|
+
Builds and returns a list of installed packages ordered so that each
|
|
103
|
+
package appears after all of its dependencies.
|
|
104
|
+
|
|
105
|
+
The function looks at the packages that are installed under the provided
|
|
106
|
+
`path` (or the application directory if omitted) and analyses their
|
|
107
|
+
`dependencies` declared in `package.json`.
|
|
108
|
+
|
|
109
|
+
#### Parameters
|
|
110
|
+
|
|
111
|
+
- `path` *(optional)* – base directory from which installed packages are
|
|
112
|
+
discovered. It should normally be the root of your application or
|
|
113
|
+
workspace (where `node_modules` can be resolved). If not provided, the
|
|
114
|
+
default application directory from `@itrocks/app-dir` is used.
|
|
115
|
+
|
|
116
|
+
#### Return value
|
|
117
|
+
|
|
118
|
+
Returns a `Promise` that resolves to an array of package names
|
|
119
|
+
(`string[]`).
|
|
120
|
+
|
|
121
|
+
The order guarantees that, whenever package **A** depends on package
|
|
122
|
+
**B**, **B** appears **before** **A** in the resulting array.
|
|
123
|
+
|
|
124
|
+
#### Errors
|
|
125
|
+
|
|
126
|
+
The `Promise` is rejected in particular when:
|
|
127
|
+
|
|
128
|
+
- a **cyclic dependency** is detected between some of the installed
|
|
129
|
+
packages. The error message lists the packages involved in the cycle;
|
|
130
|
+
- an underlying error occurs while listing installed packages
|
|
131
|
+
(filesystem access problems, invalid `package.json`, etc.).
|
|
132
|
+
|
|
133
|
+
You should treat any rejection as a signal that the dependency graph of
|
|
134
|
+
the current installation is not valid for ordered processing.
|
|
135
|
+
|
|
136
|
+
## Typical use cases
|
|
137
|
+
|
|
138
|
+
- Running **build scripts** for a set of internal packages in a
|
|
139
|
+
dependency‑safe order.
|
|
140
|
+
- Applying **database migrations** or **initialisation scripts** for
|
|
141
|
+
feature modules whose code is distributed across several packages.
|
|
142
|
+
- Generating **documentation** or **reports** that need to aggregate
|
|
143
|
+
information from each package only after its dependencies have been
|
|
144
|
+
analysed.
|
|
145
|
+
- Checking for **dependency graph issues** in a project (for example as
|
|
146
|
+
part of a CI step that fails when cycles are introduced).
|
|
147
|
+
- Implementing custom **orchestration tools** for monorepos or modular
|
|
148
|
+
backends without writing your own dependency‑resolution logic.
|
package/cjs/dependency.js
CHANGED
|
@@ -36,7 +36,7 @@ async function dependencies(path = app_dir_1.appDir) {
|
|
|
36
36
|
result.push(packageName);
|
|
37
37
|
}
|
|
38
38
|
}
|
|
39
|
-
//
|
|
39
|
+
// sort packages by their dependencies
|
|
40
40
|
let didSomething = true;
|
|
41
41
|
while (dependencies && didSomething) {
|
|
42
42
|
didSomething = false;
|
package/package.json
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
"email": "baptiste@pillot.fr"
|
|
5
5
|
},
|
|
6
6
|
"dependencies": {
|
|
7
|
-
"list-installed": "^
|
|
7
|
+
"list-installed": "^6.0"
|
|
8
8
|
},
|
|
9
9
|
"description": "Builds a dependency-sorted list of Nodes.js modules",
|
|
10
10
|
"devDependencies": {
|
|
@@ -32,7 +32,9 @@
|
|
|
32
32
|
"nodejs",
|
|
33
33
|
"order",
|
|
34
34
|
"reorder",
|
|
35
|
-
"
|
|
35
|
+
"sort",
|
|
36
|
+
"sorting",
|
|
37
|
+
"topological-sort"
|
|
36
38
|
],
|
|
37
39
|
"license": "ISC",
|
|
38
40
|
"name": "@itrocks/dependency",
|
|
@@ -44,5 +46,5 @@
|
|
|
44
46
|
"build": "tsc"
|
|
45
47
|
},
|
|
46
48
|
"types": "./cjs/dependency.d.ts",
|
|
47
|
-
"version": "0.0.
|
|
49
|
+
"version": "0.0.7"
|
|
48
50
|
}
|