@carecard/auth-util 3.6.1 → 3.8.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.
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pkg-publish
|
|
3
|
+
description: 'Use when any pkg-* repository has non-Markdown package changes, including source code, public types, tests, scripts, package metadata, lockfiles, dependency behavior, or validation config, and the CareCard packages must be versioned, published in order with just-in-time package pushes, and propagated to pkg-*, ms-*, and app-dashboard consumers. Do not use for Markdown-only changes.'
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# pkg Publish
|
|
7
|
+
|
|
8
|
+
Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, add or update the relevant validation check before changing the prose.
|
|
9
|
+
|
|
10
|
+
Non-negotiable code organization rule: Functions with the same or equivalent behavior must use the same or clearly corresponding descriptive names across CareCard repositories, and equivalent functionality must live in files with the same names within each repository's established architecture. No backward compatibility names, aliases, or duplicate locations are allowed.
|
|
11
|
+
|
|
12
|
+
## Trigger
|
|
13
|
+
|
|
14
|
+
Run this skill after every `pkg-*` repository change that touches non-Markdown
|
|
15
|
+
package files: source code, public type declarations, tests, scripts,
|
|
16
|
+
configuration, package metadata, lockfiles, dependency behavior, or validation
|
|
17
|
+
behavior.
|
|
18
|
+
|
|
19
|
+
Do not run this skill for Markdown-only changes, including README-only or
|
|
20
|
+
`*.md` skill-documentation-only updates.
|
|
21
|
+
|
|
22
|
+
## Version Rule
|
|
23
|
+
|
|
24
|
+
1. Check `package.json` in all four package repositories:
|
|
25
|
+
`pkg-common-util`, `pkg-validate`, `pkg-auth-util`, and `pkg-jwt-read`.
|
|
26
|
+
2. Select one minor version higher than the highest current package version.
|
|
27
|
+
If the highest version is `3.7.0`, the coordinated target version is
|
|
28
|
+
`3.8.0`.
|
|
29
|
+
3. Use the same target version for all four packages.
|
|
30
|
+
4. Update each package's `package.json` and `package-lock.json`, then commit the
|
|
31
|
+
version change on a package release branch before publishing.
|
|
32
|
+
|
|
33
|
+
## Publish Order
|
|
34
|
+
|
|
35
|
+
Always publish packages in this order, one repository at a time:
|
|
36
|
+
|
|
37
|
+
1. `@carecard/common-util`
|
|
38
|
+
2. `@carecard/validate`
|
|
39
|
+
3. `@carecard/auth-util`
|
|
40
|
+
4. `@carecard/jwt-read`
|
|
41
|
+
|
|
42
|
+
Publish by pushing the package release branch, creating or reusing a pull
|
|
43
|
+
request into `development`, marking it ready, waiting for checks, squash-merging
|
|
44
|
+
with administrator privileges, and verifying npm publication with:
|
|
45
|
+
|
|
46
|
+
```sh
|
|
47
|
+
npm view <package-name>@<target-version> version
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
The package GitHub workflow publishes automatically from `development`. Do not
|
|
51
|
+
create a `main` merge unless the user explicitly asks for it.
|
|
52
|
+
|
|
53
|
+
## Deferred Package Push
|
|
54
|
+
|
|
55
|
+
Commit coordinated version and dependency updates locally as the release sequence
|
|
56
|
+
progresses. Do not push a `pkg-*` release branch until that package is the next
|
|
57
|
+
package being published by merge into `development`.
|
|
58
|
+
|
|
59
|
+
Immediately before each package's publishing turn:
|
|
60
|
+
|
|
61
|
+
1. Verify the repository is on the intended release branch and has a clean
|
|
62
|
+
working tree.
|
|
63
|
+
2. Run required validation and every direct `.husky` script for that repository.
|
|
64
|
+
3. Push that package's release branch.
|
|
65
|
+
4. Create or reuse the pull request into `development`, merge it, and wait for
|
|
66
|
+
npm publication before continuing to dependency fanout.
|
|
67
|
+
|
|
68
|
+
## Dependency Fanout
|
|
69
|
+
|
|
70
|
+
After each package publishes, update every package repository that depends on
|
|
71
|
+
that package to the exact target version and commit the change before
|
|
72
|
+
continuing:
|
|
73
|
+
|
|
74
|
+
1. After publishing `@carecard/common-util`, update it in `pkg-validate`,
|
|
75
|
+
`pkg-auth-util`, and `pkg-jwt-read` when declared.
|
|
76
|
+
2. After publishing `@carecard/validate`, update it in `pkg-auth-util` and
|
|
77
|
+
`pkg-jwt-read` when declared.
|
|
78
|
+
3. After publishing `@carecard/auth-util`, update it in `pkg-jwt-read` when
|
|
79
|
+
declared.
|
|
80
|
+
4. `@carecard/jwt-read` is last, so no later package repository depends on it.
|
|
81
|
+
|
|
82
|
+
Use exact installs so `package.json` and `package-lock.json` stay aligned:
|
|
83
|
+
|
|
84
|
+
```sh
|
|
85
|
+
npm install <package-name>@<target-version> --save-exact
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
## Service And Dashboard Consumers
|
|
89
|
+
|
|
90
|
+
After all four packages are published, update all `ms-*` repositories and
|
|
91
|
+
`app-dashboard` that declare any `@carecard/*` package dependency. Install the
|
|
92
|
+
latest exact target version for every declared CareCard package, run the
|
|
93
|
+
repository's required validation, and commit the dependency updates locally.
|
|
94
|
+
|
|
95
|
+
Do not push, open pull requests, or merge service/dashboard consumer dependency
|
|
96
|
+
commits unless the user explicitly asks for remote GitHub work for those
|
|
97
|
+
repositories.
|
|
98
|
+
|
|
99
|
+
## Validation
|
|
100
|
+
|
|
101
|
+
For each changed repository:
|
|
102
|
+
|
|
103
|
+
- Run `git diff --check`.
|
|
104
|
+
- Run every direct script in `.husky`; do not bypass hooks.
|
|
105
|
+
- For package repositories, run the package tests, type checks, and lint/format
|
|
106
|
+
checks required by the hook.
|
|
107
|
+
- For `app-dashboard`, run both `.husky/pre-commit` and `.husky/pre-push` when
|
|
108
|
+
dependencies change.
|
|
109
|
+
|
|
110
|
+
Finish by verifying that all four packages are published at the same target
|
|
111
|
+
version and every declared `@carecard/*` dependency in `pkg-*`, `ms-*`, and
|
|
112
|
+
`app-dashboard` is pinned to that version.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@carecard/auth-util",
|
|
3
|
-
"version": "3.
|
|
3
|
+
"version": "3.8.0",
|
|
4
4
|
"repository": "https://github.com/CareCard-ca/pkg-auth-util.git",
|
|
5
5
|
"description": "Auth utility functions",
|
|
6
6
|
"main": "index.js",
|
|
@@ -42,8 +42,8 @@
|
|
|
42
42
|
"typescript": "6.0.3"
|
|
43
43
|
},
|
|
44
44
|
"dependencies": {
|
|
45
|
-
"@carecard/common-util": "3.
|
|
46
|
-
"@carecard/validate": "3.
|
|
45
|
+
"@carecard/common-util": "3.8.0",
|
|
46
|
+
"@carecard/validate": "3.8.0"
|
|
47
47
|
},
|
|
48
48
|
"overrides": {
|
|
49
49
|
"diff": "8.0.4",
|
|
@@ -1,79 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: npm-package-flow
|
|
3
|
-
description: 'Use in pkg-* repositories when publishable package code changes require a version bump, GitHub development/main squash-merge flow, npm publication, and uncommitted consumer package updates in ms-* and app-dashboard.'
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# npm Package Flow
|
|
7
|
-
|
|
8
|
-
Non-negotiable TDD rule: Always write the failing test first, run it to confirm it fails for the intended reason, then implement the code and rerun the test until it passes. Test Driven Development is required for all coding work and must not be skipped. For documentation- or skill-only edits, add or update the relevant validation check before changing the prose.
|
|
9
|
-
|
|
10
|
-
Non-negotiable code organization rule: Functions with the same or equivalent behavior must use the same or clearly corresponding descriptive names across CareCard repositories, and equivalent functionality must live in files with the same names within each repository's established architecture. No backward compatibility names, aliases, or duplicate locations are allowed.
|
|
11
|
-
|
|
12
|
-
## Purpose
|
|
13
|
-
|
|
14
|
-
Use this skill in a `pkg-*` repository when package code changes need to be
|
|
15
|
-
published to npm and propagated to CareCard consumers.
|
|
16
|
-
|
|
17
|
-
The package name is the `name` field in the repository `package.json`.
|
|
18
|
-
|
|
19
|
-
## Publishable vs Non-Publishable Changes
|
|
20
|
-
|
|
21
|
-
Publishable package changes include runtime source changes, public exports,
|
|
22
|
-
TypeScript declarations, package metadata that affects consumers, security
|
|
23
|
-
behavior, or dependency behavior that changes the package contract.
|
|
24
|
-
|
|
25
|
-
The following are not publishable package changes by themselves:
|
|
26
|
-
|
|
27
|
-
- Skills or `.agents` guidance.
|
|
28
|
-
- Documentation and README updates.
|
|
29
|
-
- Tests, fixtures, mocks, snapshots, or validation-only changes.
|
|
30
|
-
- Formatting-only changes and comments.
|
|
31
|
-
|
|
32
|
-
For non-publishable changes, do not bump the package version, publish to npm,
|
|
33
|
-
or update `ms-*` and `app-dashboard` package versions.
|
|
34
|
-
|
|
35
|
-
## Required Flow For Publishable Changes
|
|
36
|
-
|
|
37
|
-
Run this workflow only when the user explicitly asks for package publication,
|
|
38
|
-
remote GitHub merge work, or the full package-flow completion. Remote Git and
|
|
39
|
-
GitHub operations must not be inferred.
|
|
40
|
-
|
|
41
|
-
1. Finish package code, tests, documentation, and skill updates inside the
|
|
42
|
-
current `pkg-*` repository.
|
|
43
|
-
2. Bump the package version in `package.json` and `package-lock.json` according
|
|
44
|
-
to the user request or the package change scope.
|
|
45
|
-
3. Run the package's required tests, lint, type checks, and every direct Husky
|
|
46
|
-
script. Fix failures before continuing.
|
|
47
|
-
4. Commit the package changes to the current branch.
|
|
48
|
-
5. Push the current branch, create or reuse the PR into `development`,
|
|
49
|
-
squash-merge it with administrator privileges, and delete the merged branch.
|
|
50
|
-
6. Create a new merge branch from the updated `development` branch and use that
|
|
51
|
-
branch to open a PR into `main`.
|
|
52
|
-
7. Squash-merge the merge branch into `main` with administrator privileges and
|
|
53
|
-
delete the merge branch. This `main` merge publishes the package.
|
|
54
|
-
8. Confirm publication with `npm view <package-name>@<version> version`.
|
|
55
|
-
9. Check out a fresh local branch with the same name as the deleted working
|
|
56
|
-
branch from the updated `development` branch.
|
|
57
|
-
10. Update the new `@carecard/...` package version in `app-dashboard` and in
|
|
58
|
-
only the `ms-*` repositories that already declare the package, plus any
|
|
59
|
-
explicitly intended new consumers.
|
|
60
|
-
11. Run `npm install` and relevant validation in each updated consumer.
|
|
61
|
-
12. Do not commit the `ms-*` or `app-dashboard` consumer updates unless the user
|
|
62
|
-
explicitly asks.
|
|
63
|
-
|
|
64
|
-
## Consumer Update Rules
|
|
65
|
-
|
|
66
|
-
- Discover existing consumers by checking each target repository `package.json`
|
|
67
|
-
for the published package name.
|
|
68
|
-
- Install exact package versions, for example
|
|
69
|
-
`npm install <package-name>@<version> --save-exact`.
|
|
70
|
-
- Keep consumer updates local and uncommitted unless the user gives a separate
|
|
71
|
-
commit or PR instruction.
|
|
72
|
-
- If a consumer should become a new dependency, require explicit user intent for
|
|
73
|
-
that repository.
|
|
74
|
-
|
|
75
|
-
## Reporting
|
|
76
|
-
|
|
77
|
-
Report the package name, published version, development PR, main PR, npm
|
|
78
|
-
publication check, consumer repositories updated, validation commands run, and
|
|
79
|
-
any consumer updates intentionally left uncommitted.
|
|
@@ -1,5 +0,0 @@
|
|
|
1
|
-
interface:
|
|
2
|
-
display_name: 'npm Package Flow'
|
|
3
|
-
short_description: 'Use in pkg-* repositories when publishable @carecard package code changes need npm publication and consumer updates.'
|
|
4
|
-
brand_color: '#0F766E'
|
|
5
|
-
default_prompt: 'Use $npm-package-flow when this task matches the skill scope.'
|