@strastdas/oxc-config 0.1.2 → 0.1.3
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/QUALITY.md +75 -0
- package/README.md +2 -0
- package/package.json +2 -1
package/QUALITY.md
ADDED
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# Quality policy
|
|
2
|
+
|
|
3
|
+
`@strastdas/oxc-config` is the executable baseline for JavaScript and TypeScript repositories maintained by Strastdas. Configuration is the source of truth; this document explains how to adopt it consistently.
|
|
4
|
+
|
|
5
|
+
## Profiles
|
|
6
|
+
|
|
7
|
+
Use the narrowest applicable profile:
|
|
8
|
+
|
|
9
|
+
- `@strastdas/oxc-config/base` for Node.js services, workers, CLIs, libraries, and non-Next applications.
|
|
10
|
+
- `@strastdas/oxc-config/next-react` for Next.js applications and React code that is intentionally governed by Next rules.
|
|
11
|
+
|
|
12
|
+
Do not apply `next-react` to Vite, Expo/React Native, Rust/Tauri, Swift, Kotlin, generated, or vendor code solely for convenience. Add a scoped configuration or exclude non-JS/TS and generated paths instead.
|
|
13
|
+
|
|
14
|
+
## Required checks
|
|
15
|
+
|
|
16
|
+
Every adopted repository should expose check-only commands for:
|
|
17
|
+
|
|
18
|
+
1. Oxlint with the appropriate shared profile.
|
|
19
|
+
2. Oxfmt formatting verification.
|
|
20
|
+
3. TypeScript typechecking.
|
|
21
|
+
4. The repository's relevant build and test commands.
|
|
22
|
+
|
|
23
|
+
Example:
|
|
24
|
+
|
|
25
|
+
```json
|
|
26
|
+
{
|
|
27
|
+
"scripts": {
|
|
28
|
+
"lint:oxc": "oxlint --config oxlint.config.mjs src",
|
|
29
|
+
"format:check:oxc": "oxfmt --config oxfmt.config.mjs --check src",
|
|
30
|
+
"check": "pnpm lint:oxc && pnpm format:check:oxc && pnpm typecheck"
|
|
31
|
+
}
|
|
32
|
+
}
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Use project-specific scope paths rather than linting native, generated, cache, build, or vendor directories.
|
|
36
|
+
|
|
37
|
+
## Formatting
|
|
38
|
+
|
|
39
|
+
Oxfmt is the canonical formatter for adopted repositories. Each repository owns its `oxfmt.config.*` because formatter compatibility is inherently local:
|
|
40
|
+
|
|
41
|
+
- preserve intentional quote, semicolon, line-ending, and print-width conventions during migration;
|
|
42
|
+
- configure Tailwind sorting with the repository's stylesheet and `cn`/`cva` helpers when applicable;
|
|
43
|
+
- ignore generated, cache, native, and vendor paths explicitly;
|
|
44
|
+
- make formatter rewrites a dedicated, reviewable mechanical commit.
|
|
45
|
+
|
|
46
|
+
Do not mix broad formatting churn with behavior changes.
|
|
47
|
+
|
|
48
|
+
## Migration policy
|
|
49
|
+
|
|
50
|
+
Adoption happens in stages:
|
|
51
|
+
|
|
52
|
+
1. Add pinned tooling, scoped configs, and check-only scripts.
|
|
53
|
+
2. Record the initial Oxc and Oxfmt baseline without weakening shared rules.
|
|
54
|
+
3. Fix findings in focused, verified commits. Prioritize correctness, accessibility, type safety, and real build failures.
|
|
55
|
+
4. Make the checks required in CI only after the baseline is clean or has explicitly reviewed compatibility exceptions.
|
|
56
|
+
|
|
57
|
+
A nonzero advisory baseline is acceptable during migration. Do not silently replace it with broad rule disablement.
|
|
58
|
+
|
|
59
|
+
## Local exceptions
|
|
60
|
+
|
|
61
|
+
Shared rules must not be weakened globally to accommodate one codebase. When an exception is genuinely necessary:
|
|
62
|
+
|
|
63
|
+
- prefer a direct code fix;
|
|
64
|
+
- otherwise use the narrowest file, directory, or inline suppression possible;
|
|
65
|
+
- write a concrete rationale explaining why the pattern is intentional and safe;
|
|
66
|
+
- keep accessibility and type-safety rules enabled globally;
|
|
67
|
+
- never suppress generated or vendor code by changing policy for authored code.
|
|
68
|
+
|
|
69
|
+
Examples of valid narrow exceptions include verified SDK type boundaries, intentional sequential awaits, generated code, and framework patterns that a compiler rule misidentifies. Complexity or readability exceptions must document the preserved domain behavior.
|
|
70
|
+
|
|
71
|
+
## CI and templates
|
|
72
|
+
|
|
73
|
+
Once clean, require the repository's quality checks on pull requests. Keep build and tests as separate required gates.
|
|
74
|
+
|
|
75
|
+
New repositories should start from the organization templates with this package, scoped Oxc/Oxfmt configs, and the required scripts already present. Repository-local `AGENTS.md` or `docs/quality.md` should link here and document only local scope mappings, ignores, and approved exceptions.
|
package/README.md
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@strastdas/oxc-config",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.3",
|
|
4
4
|
"description": "Shared Oxlint compatibility presets for Ultracite projects.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"type": "module",
|
|
@@ -20,6 +20,7 @@
|
|
|
20
20
|
"next-react.mjs",
|
|
21
21
|
"next-react.d.mts",
|
|
22
22
|
"README.md",
|
|
23
|
+
"QUALITY.md",
|
|
23
24
|
"LICENSE"
|
|
24
25
|
],
|
|
25
26
|
"peerDependencies": {
|