nx-lifecycle 0.2.0 → 0.2.1

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 (5) hide show
  1. package/README.md +9 -9
  2. package/dist/lifecycle/schema.js +1 -1
  3. package/dist/schemas/lib/ajv.d.ts +2 -2
  4. package/dist/schemas/lib/ajv.js +3 -5
  5. package/package.json +25 -25
package/README.md CHANGED
@@ -26,26 +26,26 @@ Nx uses the target's [dependsOn](https://nx.dev/reference/project-configuration#
26
26
 
27
27
  In practice, this quickly becomes unweildy. In order to properly configure a given task, you have to have full context about all other tasks (including those of your dependencies). You also need to make sure all dependents are updated whenever you add another step to a task.
28
28
 
29
- For example, perhaps your code contains a typescript build step [nx-tsc](https://www.npmjs.com/package/nx-tsc), followed by a unit test [mocha](https://mochajs.org/). An initial config will look like:
29
+ For example, perhaps your code contains a typescript build step [tsc](https://www.typescriptlang.org/docs/handbook/compiler-options.html), followed by a unit test [mocha](https://mochajs.org/). An initial config will look like:
30
30
 
31
31
  ```json
32
32
  {
33
33
  "targets": {
34
- "nx-tsc": {
35
- "dependsOn": ["^nx-tsc"]
34
+ "tsc": {
35
+ "dependsOn": ["^tsc"]
36
36
  },
37
37
  "mocha": {
38
- "dependsOn": ["nx-tsc"]
38
+ "dependsOn": ["tsc"]
39
39
  },
40
40
  }
41
41
  }
42
42
  ```
43
43
 
44
- Your mocha task depends on the nx-tsc first, and nx-tsc depends on any of _its_ dependencies to be built first.
44
+ Your mocha task depends on the tsc first, and tsc depends on any of _its_ dependencies to be built first.
45
45
 
46
- Now what if you need want to add a step _after_ to your build? Perhaps you want to use your recently built JS code to [generate a JSON config](https://www.npmjs.com/package/nx-populate-files).
46
+ Now what if you need want to add a step _after_ to your build? Perhaps you want to use your recently built JS code to [generate a JSON config](https://www.npmjs.com/package/load-populate-files).
47
47
 
48
- Now your mocha command needs to update to depend on that populate step, rather than `nx-tsc`. Your `nx-tsc` command _also_ needs to update its dependencies to depend on that task, rather than `nx-tsc`. But only if your dependencies include this populate step!
48
+ Now your mocha command needs to update to depend on that populate step, rather than `tsc`. Your `tsc` command _also_ needs to update its dependencies to depend on that task, rather than `tsc`. But only if your dependencies include this populate step!
49
49
 
50
50
  Instead of simply adding this new task, you now need to conditionally manage the dependecones on two other tasks! Imagine how this problem can grow as we begin to support more tasks like type checking, code coverage, or codegen. Each implemented slightly different in each package, especailly if you use more than one language in your monorepo!
51
51
 
@@ -66,7 +66,7 @@ Note these steps are still abstract, and it is not necessary that every project
66
66
 
67
67
  Now we can bind project specific implementations to each abstract task.
68
68
 
69
- In the original example, perhaps we bind our `nx-tsc` target to a `build:run` step, and our `nx-populate-files` step to a `build:post` step.
69
+ In the original example, perhaps we bind our `tsc` target to a `build:run` step, and our `load-populate-files` step to a `build:post` step.
70
70
 
71
71
  Then our `mocha` target can be bound to a `test:unit` step.
72
72
 
@@ -202,7 +202,7 @@ Required. No default value.
202
202
 
203
203
  This is [bind implementions to tasks](#bind-implementions-to-tasks) logic as described above.
204
204
 
205
- The value is an object mapping, where the key is the name of your specific target implementations (e.g. `nx-tsc` or `mocha`) and the value is the stage it maps to.
205
+ The value is an object mapping, where the key is the name of your specific target implementations (e.g. `tsc` or `mocha`) and the value is the stage it maps to.
206
206
 
207
207
  __\*\*NOTE\*\*__ If the bound stage has `steps` defined, then you must bind to a specific step. If there are no steps, then you reference the stage directly.
208
208
 
package/dist/lifecycle/schema.js CHANGED
@@ -5,7 +5,7 @@ const checkAndDryRunSchema = objectSchema({
5
5
  properties: {
6
6
  $schema: stringSchema({
7
7
  description: '',
8
- format: 'uri'
8
+ format: 'uri-reference'
9
9
  }).example('https://raw.githubusercontent.com/JacobLey/leyman/refs/heads/main/apps/nx-lifecycle/src/lifecycle/schema.json'),
10
10
  check: booleanSchema({
11
11
  description: 'Fails if references are not already updated, will not overwrite. Defaults to true during CI, false otherwise.'
package/dist/schemas/lib/ajv.d.ts CHANGED
@@ -1,3 +1,3 @@
1
- import AjvDefault from 'ajv/dist/2020.js';
2
- export declare const ajv: AjvDefault.Ajv2020;
1
+ import { Ajv2020 } from 'ajv/dist/2020.js';
2
+ export declare const ajv: Ajv2020;
3
3
  //# sourceMappingURL=ajv.d.ts.map
package/dist/schemas/lib/ajv.js CHANGED
@@ -1,10 +1,8 @@
1
- import AjvDefault from 'ajv/dist/2020.js';
2
- import { defaultImport } from 'default-import';
3
- const Ajv = defaultImport(AjvDefault);
4
- export const ajv = new Ajv({
1
+ import { Ajv2020 } from 'ajv/dist/2020.js';
2
+ export const ajv = new Ajv2020({
5
3
  strict: true,
6
4
  formats: {
7
- uri: true
5
+ 'uri-reference': true
8
6
  }
9
7
  });
10
8
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "nx-lifecycle",
3
- "version": "0.2.0",
3
+ "version": "0.2.1",
4
4
  "description": "Keep high level nx lifecycle targets in sync",
5
5
  "engines": {
6
6
  "node": ">=20"
@@ -37,44 +37,44 @@
37
37
  "lifecycle": "./bin.mjs"
38
38
  },
39
39
  "dependencies": {
40
- "@nx/devkit": "^20.3.0",
40
+ "@nx/devkit": "^20.4.2",
41
41
  "ajv": "^8.17.1",
42
42
  "ci-info": "^4.1.0",
43
- "fast-equals": "^5.0.1",
44
- "nx": "^20.3.0",
43
+ "fast-equals": "^5.2.2",
44
+ "nx": "^20.4.2",
45
45
  "yargs": "^17.7.2",
46
- "common-proxy": "^0.1.2",
47
- "format-file": "^0.1.4",
48
- "entry-script": "^3.0.8",
49
- "haywire": "^0.1.7",
50
- "haywire-launcher": "^0.1.10",
51
- "default-import": "^2.0.7",
52
- "juniper": "^1.2.4",
53
- "parse-cwd": "^1.1.1",
54
- "nx-plugin-handler": "^0.2.0"
46
+ "default-import": "^2.0.8",
47
+ "entry-script": "^3.0.9",
48
+ "format-file": "^0.1.5",
49
+ "haywire-launcher": "^0.1.11",
50
+ "common-proxy": "^0.1.3",
51
+ "nx-plugin-handler": "^0.2.1",
52
+ "haywire": "^0.1.8",
53
+ "parse-cwd": "^1.1.2",
54
+ "juniper": "^1.2.5"
55
55
  },
56
56
  "devDependencies": {
57
57
  "@biomejs/biome": "^1.9.4",
58
- "@swc/cli": "^0.5.2",
59
- "@swc/core": "^1.10.4",
58
+ "@swc/cli": "^0.6.0",
59
+ "@swc/core": "^1.10.15",
60
60
  "@types/chai": "^5.0.1",
61
61
  "@types/chai-as-promised": "^8.0.1",
62
62
  "@types/mocha": "^10.0.10",
63
- "@types/node": "^22.10.2",
63
+ "@types/node": "^22.13.1",
64
64
  "@types/sinon": "^17.0.3",
65
65
  "@types/yargs": "^17.0.33",
66
66
  "c8": "^10.1.3",
67
67
  "chai": "^5.1.2",
68
68
  "chai-as-promised": "^8.0.1",
69
- "eslint": "^9.17.0",
70
- "mocha": "^11.0.1",
69
+ "eslint": "^9.20.0",
70
+ "mocha": "^11.1.0",
71
71
  "sinon": "^19.0.2",
72
- "typescript": "^5.7.2",
73
- "load-populate-files": "^0.1.1",
74
- "mocha-chain": "^0.0.10",
75
- "nx-update-ts-references": "^0.2.0",
76
- "@leyman/eslint-config": "^0.0.5",
77
- "pnpm-dedicated-lockfile": "^0.0.3",
78
- "sinon-typed-stub": "^0.0.10"
72
+ "typescript": "^5.7.3",
73
+ "@leyman/eslint-config": "^0.0.1",
74
+ "load-populate-files": "^0.1.2",
75
+ "nx-update-ts-references": "^0.2.1",
76
+ "pnpm-dedicated-lockfile": "^0.0.4",
77
+ "mocha-chain": "^0.0.11",
78
+ "sinon-typed-stub": "^0.0.11"
79
79
  }
80
80
  }