@sha3/code-standards 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/README.md CHANGED
@@ -112,6 +112,8 @@ After `init`, your new repo contains:
112
112
 
113
113
  That means the next step is **not** configuring tools. The next step is telling your assistant to obey `AGENTS.md` before coding.
114
114
 
115
+ Generated project code is TypeScript-only: implementation and tests live in `.ts` files.
116
+
115
117
  ## TypeScript Example Files
116
118
 
117
119
  `init` now stores code examples in `.ts` files instead of embedding them inside `AGENTS.md`.
@@ -278,6 +280,7 @@ Commands:
278
280
  ### `init` options
279
281
 
280
282
  `init` always uses the current working directory as target.
283
+ An existing `.git/` directory is allowed without `--force`.
281
284
 
282
285
  - `--template <node-lib|node-service>`
283
286
  - `--yes`
@@ -394,8 +394,9 @@ async function ensureTargetReady(targetPath, force) {
394
394
  }
395
395
 
396
396
  const entries = await readdir(targetPath);
397
+ const nonGitEntries = entries.filter((entry) => entry !== ".git");
397
398
 
398
- if (entries.length > 0 && !force) {
399
+ if (nonGitEntries.length > 0 && !force) {
399
400
  throw new Error(
400
401
  `Target directory is not empty: ${targetPath}. Use --force to continue and overwrite files.`
401
402
  );
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@sha3/code-standards",
3
- "version": "0.1.2",
3
+ "version": "0.1.3",
4
4
  "description": "AI-first code standards, tooling exports, and project initializer",
5
5
  "type": "module",
6
6
  "bin": {
@@ -4,6 +4,8 @@
4
4
  - Functions MUST implement one responsibility.
5
5
  - Long functions MUST be split into private helper methods.
6
6
  - Types MUST be preferred over interfaces for local modeling unless a public contract requires an interface.
7
+ - New implementation and test files MUST be `.ts`.
8
+ - JavaScript source files (`.js`, `.mjs`, `.cjs`) are not allowed in `src/` or `test/`.
7
9
 
8
10
  Good example:
9
11
 
@@ -2,6 +2,7 @@
2
2
 
3
3
  - Any behavior change MUST include or update tests.
4
4
  - Tests MUST validate behavior, not implementation details.
5
+ - Test files MUST be TypeScript (`*.test.ts`).
5
6
  - Comments MUST be explicit and extensive when logic is non-trivial.
6
7
  - Async workflows MUST use `async/await` style only.
7
8
 
@@ -15,7 +15,7 @@ Both templates SHOULD keep this baseline structure:
15
15
 
16
16
  - `src/` for implementation.
17
17
  - `test/` for automated tests.
18
- - `eslint.config.mjs`, `prettier.config.cjs`, and `tsconfig.json` at root.
18
+ - Root tooling config files (`eslint`, `prettier`, `tsconfig`) at project root.
19
19
 
20
20
  ## Boundary Rules
21
21
 
@@ -12,6 +12,8 @@ All code MUST follow the canonical rules in `standards/manifest.json`.
12
12
  ## TypeScript
13
13
 
14
14
  - Use strict TypeScript mode.
15
+ - Project implementation and tests MUST be TypeScript-only (`.ts`).
16
+ - JavaScript source files (`.js`, `.mjs`, `.cjs`) are not allowed in `src/` or `test/`.
15
17
  - Avoid `any` unless there is no viable alternative.
16
18
  - Prefer explicit return types for exported functions.
17
19
  - Use type-only imports when possible.
@@ -5,7 +5,7 @@ Projects MUST use the Node test runner.
5
5
  ## Location
6
6
 
7
7
  - Store tests under `test/`.
8
- - Use `*.test.ts` or `*.test.js` naming.
8
+ - Use `*.test.ts` naming only.
9
9
 
10
10
  ## Commands
11
11