vrr/qwen-code
2
0
Fork 0
mirror of https://github.com/QwenLM/qwen-code.git synced 2026-05-13 23:52:40 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 20

docs(attribution): correct legacyTypes / EXCLUDED_DIRECTORY_SEGMENTS comments

Browse source 
9Ta_ (Copilot): the JSDoc on legacyTypes claimed JSON Schema's
`type` keyword does not accept `'object'` — that's wrong; `'object'`
IS a valid JSON Schema type. Reword to reflect the actual rationale:
`'enum'` is not a valid JSON Schema `type` value at all (enum
constraints use the `enum` keyword), and a bare `{type: 'object'}`
would accept any object regardless of what the field's pre-expansion
shape actually allowed. The narrowed `boolean | string | number |
array` set is exactly what the one-liner generator can faithfully
emit; richer legacy shapes belong in their own branch of
convertSettingToJsonSchema.

9Tbs (Copilot): the comment in generatedFiles.ts referenced
`EXCLUDED_DIRECTORIES`, but the constant is `EXCLUDED_DIRECTORY_SEGMENTS`
(renamed during the segment-boundary refactor). Update the
reference so a future maintainer scanning for the rule doesn't
chase a non-existent identifier.
This commit is contained in:
wenshao 2026-05-06 20:47:43 +08:00
parent a66a21d81d
commit cc916b528e
2 changed files with 13 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

20
packages/cli/src/config/settingsSchema.ts
View file

@ -85,14 +85,18 @@ export interface SettingDefinition {
* migration is still pending. Has no runtime effect — it's purely a
* compatibility hint for editors.
*
* Restricted to JSON-Schema primitive types: the schema generator emits
* `{ type: <legacyType> }` for each entry, and JSON Schema's `type`
* keyword does not accept `'enum'` or `'object'` as a literal value.
* Allowing the full SettingsType union here would let `legacyTypes:
* ['enum']` slip in and produce a syntactically invalid
* `settings.schema.json`. Future legacy shapes that need `enum` /
* complex object compatibility should land their own branch in
* `convertSettingToJsonSchema` instead of widening this set.
* Narrowed to the subset our generator can faithfully emit as a
* one-liner `{ type: <legacyType> }` schema fragment. `'enum'` is
* not a valid JSON Schema `type` value at all (enum constraints
* use the `enum` keyword, not `type: 'enum'`), so allowing it here
* would silently produce an invalid `settings.schema.json`.
* `'object'` IS a valid JSON Schema type, but a bare
* `{ type: 'object' }` legacy entry would accept ANY object value
* — most likely not what the field's pre-expansion shape actually
* permitted. Future legacy shapes that need `enum` / structured-
* object compatibility should land their own branch in
* `convertSettingToJsonSchema` (with proper `enum:` / `properties:`
* companions) instead of widening this set.
*/
legacyTypes?: ReadonlyArray<'boolean' | 'string' | 'number' | 'array'>;
}

2
packages/core/src/services/generatedFiles.ts
View file

@ -40,7 +40,7 @@ const EXCLUDED_FILENAMES = new Set([
// and treating every one as generated would silently drop AI edits
// to those files. Auto-generated `.d.ts` (e.g. `tsc --declaration`
// output) tends to live under `/dist/`, `/build/`, or `/out/`,
// which are already covered by `EXCLUDED_DIRECTORIES`.
// which are already covered by `EXCLUDED_DIRECTORY_SEGMENTS`.
const EXCLUDED_EXTENSIONS = new Set([
'.min.js',
'.min.css',