@vyriy/eslint-config 0.1.23 → 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 (3) hide show
  1. package/AGENTS.md +65 -0
  2. package/README.md +2 -0
  3. package/package.json +2 -1
package/AGENTS.md ADDED
@@ -0,0 +1,65 @@
1
+ # Vyriy Package Agent Guide
2
+
3
+ This package belongs to the Vyriy toolkit. Keep changes calm, explicit, reusable, and easy to reason about.
4
+
5
+ ## Architecture
6
+
7
+ - Prefer simple modules over clever frameworks or hidden conventions.
8
+ - Keep package boundaries explicit and avoid project-specific coupling.
9
+ - Extract only proven reusable behavior.
10
+ - Keep public APIs small, typed, documented, and stable.
11
+ - Prefer SSR-friendly and SSG-friendly code paths.
12
+ - Keep integrations replaceable and avoid hard coupling to a CMS or runtime host.
13
+ - Prefer AWS serverless-compatible assumptions when infrastructure concerns appear.
14
+
15
+ ## File Shape
16
+
17
+ - Prefer one exported runtime method, component, or helper per production file when it stays readable.
18
+ - Prefer one matching test file per production file, for example `feature.ts` and `feature.test.ts`.
19
+ - Use focused folders when behavior naturally splits into several related files.
20
+ - Keep `index.ts` as a public re-export surface only. Do not place implementation logic in it.
21
+ - Use `.js` relative import and export specifiers in TypeScript source where package style requires it.
22
+ - Add `types.ts` when public shared types are part of the package contract.
23
+ - Keep constants near the code that owns them unless they are shared or clarify repeated behavior.
24
+
25
+ ## Public Surface
26
+
27
+ - Every new public export should be re-exported from `index.ts`.
28
+ - Add or update `index.test.ts` when the public export surface changes.
29
+ - Add JSDoc for public exports when behavior, parameters, return values, or usage expectations need explanation.
30
+ - Do not hand-maintain source package `exports` maps unless the package has a real custom publishing need.
31
+
32
+ ## Tests
33
+
34
+ - Tests use Jest and `@jest/globals`.
35
+ - Cover public behavior and meaningful edge cases.
36
+ - Prefer behavior-focused tests over private implementation lock-in.
37
+ - When mocking modules, install mocks before loading the module under test.
38
+ - Use focused validation when changing package behavior:
39
+
40
+ ```bash
41
+ yarn jest packages/<package> --runInBand --coverage=false
42
+ ```
43
+
44
+ ## Documentation
45
+
46
+ - Keep `README.md` concise and usage-oriented.
47
+ - Start package READMEs with `# @vyriy/<package>`.
48
+ - Document real public exports, supported options, and examples that actually work.
49
+ - Keep `doc.mdx` as the Storybook/docs wrapper for the README when the package participates in docs.
50
+ - For component packages, include Storybook coverage for supported states and common usage.
51
+
52
+ ## Components
53
+
54
+ - Prefer lightweight React 19+ components with TypeScript.
55
+ - Keep components SSR-friendly and avoid browser globals during render.
56
+ - Prefer composable props and Bootstrap-compatible ergonomics where practical.
57
+ - Put each public component in its own file with a matching test.
58
+ - Add Storybook stories when a component has visual states, variants, or interaction states.
59
+
60
+ ## Change Discipline
61
+
62
+ - Keep changes scoped to the requested behavior.
63
+ - Avoid unrelated refactors and metadata churn.
64
+ - Sync implementation, tests, README, `doc.mdx`, and public re-exports together.
65
+ - Prefer the option that is simpler to explain, easier to evolve, and calmer to maintain.
package/README.md CHANGED
@@ -127,3 +127,5 @@ Formatting issues are reported by ESLint as warnings through `prettier/prettier`
127
127
  The package depends on `prettier` directly so consumers of `@vyriy/eslint-config` do not need to install Prettier only to satisfy the plugin runtime.
128
128
 
129
129
  Projects that also run the Prettier CLI should still install or expose `prettier` in that project so commands like `prettier . --check` are available.
130
+
131
+ See the article with a complete linting setup walkthrough: <https://vyriy.dev/examples/vyriy-eslint-config/>.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@vyriy/eslint-config",
3
- "version": "0.1.23",
3
+ "version": "0.2.1",
4
4
  "description": "Shared ESLint config for Vyriy projects",
5
5
  "type": "module",
6
6
  "main": "./index.js",
@@ -21,6 +21,7 @@
21
21
  "prettier": "^3.8.3",
22
22
  "storybook": "^10.3.6"
23
23
  },
24
+ "agents": "./AGENTS.md",
24
25
  "license": "MIT",
25
26
  "repository": {
26
27
  "type": "git",