@vyriy/handler 0.9.0 → 0.9.2
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/AGENTS.md +10 -3
- package/package.json +6 -6
package/AGENTS.md
CHANGED
|
@@ -14,6 +14,7 @@ Always read the root `AGENTS.md` first for current project direction, then use t
|
|
|
14
14
|
- Avoid hidden framework, CMS, browser, filesystem, network, or cloud assumptions unless they are the package contract.
|
|
15
15
|
- Add packages only when they reduce real complexity, clarify boundaries, or improve reuse.
|
|
16
16
|
- Prefer the option that is simpler to explain, easier to evolve, and calmer to maintain.
|
|
17
|
+
- Grow package functionality in small, calm, reviewable steps that are easy to test and continue.
|
|
17
18
|
|
|
18
19
|
## Standard Package Shape
|
|
19
20
|
|
|
@@ -84,6 +85,8 @@ Documentation must move with code. Do not finish a package change while docs des
|
|
|
84
85
|
- Keep `doc.mdx` aligned with the README and package title when packages are added, renamed, or reorganized.
|
|
85
86
|
- Add or update JSDoc for public exports when behavior, parameters, return values, errors, side effects, or usage expectations need explanation.
|
|
86
87
|
- For component packages, include visual documentation, stories, or examples for supported states, variants, and interaction states.
|
|
88
|
+
- Keep reusable components as dumb as practical: push data shaping, stateful orchestration, and demo-specific logic into the entry point or owning composition layer.
|
|
89
|
+
- Store demo data in stories instead of embedding it in reusable component source.
|
|
87
90
|
- Avoid broad architecture essays in package READMEs; keep architectural direction in root-level docs unless it is necessary to use the package.
|
|
88
91
|
|
|
89
92
|
## Tests Are Required
|
|
@@ -94,9 +97,11 @@ Tests should protect public behavior and meaningful regression risk.
|
|
|
94
97
|
- Add a real test immediately for new packages. If behavior is not finalized, add a valid placeholder test with a clear public API expectation.
|
|
95
98
|
- Prefer behavior-focused tests over private implementation lock-in.
|
|
96
99
|
- Keep tests deterministic and avoid real network, timers, browser, filesystem, or cloud dependencies unless that dependency is the behavior under test.
|
|
100
|
+
- Mock external dependencies from `node_modules` in unit tests so package behavior stays deterministic and local.
|
|
97
101
|
- When mocking modules, install mocks before loading the module under test.
|
|
98
102
|
- Use `@jest/globals` in Jest tests.
|
|
99
|
-
-
|
|
103
|
+
- Keep coverage enabled for normal validation. The shared Jest config in `packages/jest/index.ts` requires 100% global coverage for branches, functions, lines, and statements.
|
|
104
|
+
- For small changes, run Jest against the changed tests or changed package with coverage enabled. For larger package changes, public API changes, or cross-package changes, run the full Jest suite with coverage.
|
|
100
105
|
|
|
101
106
|
Typical package test naming:
|
|
102
107
|
|
|
@@ -127,10 +132,12 @@ Preferred validation commands:
|
|
|
127
132
|
yarn tsc --pretty false
|
|
128
133
|
yarn eslint <changed files or package>
|
|
129
134
|
yarn prettier --check <changed files or package>
|
|
130
|
-
yarn jest <changed tests or package> --runInBand
|
|
135
|
+
yarn jest <changed tests or package> --runInBand
|
|
131
136
|
```
|
|
132
137
|
|
|
133
|
-
|
|
138
|
+
Run ESLint after YAML/YML changes too, for example `yarn eslint <changed.yml>`, because the repo ESLint setup validates YAML files as well.
|
|
139
|
+
|
|
140
|
+
Also run `yarn build:dist` for package export, manifest, build-shape, or generated-dist behavior changes. After larger package or library changes, run the full Jest suite with coverage and prefer building the affected library/package as an additional confidence check.
|
|
134
141
|
|
|
135
142
|
If a required validation command cannot be run, state why and report the remaining risk.
|
|
136
143
|
|
package/package.json
CHANGED
|
@@ -1,16 +1,16 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@vyriy/handler",
|
|
3
|
-
"version": "0.9.
|
|
3
|
+
"version": "0.9.2",
|
|
4
4
|
"description": "Composable AWS Lambda handler chains and wrappers for Vyriy projects",
|
|
5
5
|
"homepage": "https://vyriy.dev/docs/handler/",
|
|
6
6
|
"type": "module",
|
|
7
7
|
"dependencies": {
|
|
8
8
|
"@types/aws-lambda": "^8.10.162",
|
|
9
|
-
"@vyriy/chaos": "0.9.
|
|
10
|
-
"@vyriy/config": "0.9.
|
|
11
|
-
"@vyriy/logger": "0.9.
|
|
12
|
-
"@vyriy/smoke": "0.9.
|
|
13
|
-
"@vyriy/timeout": "0.9.
|
|
9
|
+
"@vyriy/chaos": "0.9.2",
|
|
10
|
+
"@vyriy/config": "0.9.2",
|
|
11
|
+
"@vyriy/logger": "0.9.2",
|
|
12
|
+
"@vyriy/smoke": "0.9.2",
|
|
13
|
+
"@vyriy/timeout": "0.9.2"
|
|
14
14
|
},
|
|
15
15
|
"agents": "./AGENTS.md",
|
|
16
16
|
"license": "MIT",
|