Standardize DTO naming and folder placement across 61 DTO files
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- node.js, typescript
- Domain
- api
Research direction
Start with src/infrastructure/file-upload/dto/file-upload.dto.ts and CONTRIBUTING.md to understand the current DTOs and the proposed convention. Audit the 61 *.dto.ts files under src/, and review docs/openapi.json before any class rename. Done means the convention and audit are documented, the file-upload DTOs are split without breaking published schema names or validation responses, and npx tsc --noEmit and npm test pass.
Written by the indexing model from the issue text.
Description
Problem
61 files match *.dto.ts across src/. They do not follow a consistent convention. Observed inconsistencies:
src/investment/portfolio/dto/portfolio-management.dto.ts— multiple DTOs in one filesrc/infrastructure/file-upload/dto/file-upload.dto.ts— six DTOs in one file (UploadFileDto,UpdateFileMetadataDto,GenerateThumbnailDto,GetDownloadUrlDto,FileSearchDto,FileCleanupDto)- Some directories use
dto/, others may not.
Class-validator coverage is uneven too: 151 @Max/@Min validators exist across the DTO set, but pagination limit fields frequently lack an upper bound — see the separate pagination-bounds issue.
Why it matters
Naming and placement drift is invisible until someone searches for a DTO and finds it in an unexpected file, or tries to import it and hits a circular reference caused by a barrel. It also makes DTO review harder — a 200-line multi-DTO file gets a per-file review, whereas small per-DTO files get focused attention.
For the generated OpenAPI spec it matters more: DTO file layout does not affect the output, but the naming does, and operationId/schema names derive from class names. Inconsistent naming produces inconsistent SDK method names across TypeScript and Python, which are published artifacts.
Suggested Direction
- Write down the convention first in
CONTRIBUTING.md(see the CONTRIBUTING issue):- one primary DTO per file, named
<Domain><Action>Dto(e.g.CreatePortfolioDto,UpdateFileMetadataDto) - colocate in a
dto/directory under the owning module - request DTOs and response DTOs in separate files where the shapes differ substantially
- one primary DTO per file, named
- Audit the 61 files against it and produce a summary of deviations.
- Migrate incrementally, one module at a time —
src/infrastructure/file-upload/first since its six-DTO single file is the worst offender. - Do not rename a DTO class without checking
docs/openapi.json: the class name becomes the published schema name, so a rename is a breaking SDK change.
Constraints
- Class renames are breaking for generated SDKs. If a rename is needed, coordinate a major SDK version or keep the old name and add a deprecated alias.
src/common/pipes/validation.pipe.tsformats errors into{ field, constraints, messages, children }. Any DTO restructuring must keep that response shape, since clients depend on it and there are tests on it.- Keep
class-validatordecorators consistent —@IsOptional()plus explicit validators rather than relying on inference.
Acceptance Criteria
- The convention is documented in
CONTRIBUTING.md. - A deviation audit exists covering all 61 DTO files.
-
src/infrastructure/file-upload/dto/is split into per-DTO files. - No DTO class name changes without a corresponding
docs/openapi.jsonreview. -
npx tsc --noEmitandnpm testpass.
- Dominant language
- TypeScript
- Stars
- 7
- Forks
- 55
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 5
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SourceXXL/alian_structure-api
-
good first issue help wanted security
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SourceXXL/alian_structure-api#266 ·
-
Parallelize the cache-warming loop in `cache-warming.service.ts` — warmers run strictly sequentiallyPossibly taken @syntaxsuuvam-spec claimed this 6 days ago. Opengood first issue performance
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SourceXXL/alian_structure-api#240 ·
-
documentation help wanted intermediate refactor
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
SourceXXL/alian_structure-api#215 ·
-
good first issue refactor tooling
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
SourceXXL/alian_structure-api#199 ·
-
help wanted intermediate refactor
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
SourceXXL/alian_structure-api#196 ·
All issues in SourceXXL/alian_structure-api
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
anomalyco/opencode#56380 · 1 comment ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
BUG | `MCP 服务器` | 全局层行的停用/启用与删除报 404 server row not found，编辑保存会在 profile 层复制出重复行Possibly taken @w6242652 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Chocobozzz/PeerTube#7832 ·
Maintainers usually reply within 3 days
-
Pay to use?Open
Difficulty 1/5 Under an hour Newbie friendliness 66/100
darkreader/darkreader#16108 · 1 comment ·
Maintainers usually reply within 2 days