@carecard/auth-util 3.6.1 → 3.9.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.
@@ -0,0 +1,5 @@
1
+ interface:
2
+ display_name: 'pkg Publish'
3
+ short_description: 'Publish CareCard packages in order with just-in-time pushes.'
4
+ brand_color: '#0F766E'
5
+ default_prompt: 'Use $pkg-publish to publish coordinated CareCard package releases.'
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@carecard/auth-util",
3
- "version": "3.6.1",
3
+ "version": "3.9.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.6.1",
46
- "@carecard/validate": "3.6.1"
45
+ "@carecard/common-util": "3.9.0",
46
+ "@carecard/validate": "3.9.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.'