Add Angular 21 and NestJS tech preset to installation wizard#569
Add Angular 21 and NestJS tech preset to installation wizard#569Silvino-Miranda wants to merge 3 commits intoSynkraAI:mainfrom
Conversation
Silvino-Miranda
requested review from
Pedrovaleriolopez and
oalanicolas
as code owners
|
@Silvino-Miranda is attempting to deploy a commit to the Pedro Valério Lopez's projects Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughA new "angular-nestjs" technology preset was added: a comprehensive tech-preset Markdown file, registry and manifest entries updated to include it, a template entry added, and an installer wizard option added for selection. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip You can customize the high-level summary generated by CodeRabbit.Configure the |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Welcome to aiox-core! Thanks for your first pull request.
What happens next?
- Automated checks will run on your PR
- A maintainer will review your changes
- Once approved, we'll merge your contribution!
PR Checklist:
- Tests pass (
npm test) - Linting passes (
npm run lint) - Commit messages follow Conventional Commits
Thanks for contributing!
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.aiox-core/install-manifest.yaml (1)
1-3:⚠️ Potential issue | 🟡 MinorManifest metadata mismatch—regenerate with
npm run generate:manifest.The manifest entry for
angular-nestjs.mdlists a file size of 22,621 bytes, but the actual file is 21,910 bytes. The hash matches correctly, but the stale size metadata indicates the manifest was not properly regenerated. Runnpm run generate:manifestto update both hash and size entries.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/install-manifest.yaml around lines 1 - 3, The manifest metadata for angular-nestjs.md has a stale file size; regenerate the install manifest by running the generate script so size and hash entries are recalculated: run the project script (npm run generate:manifest) to update the entry for angular-nestjs.md and commit the updated .aiox-core/install-manifest.yaml so the size (and hash if changed) match the actual file.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.aiox-core/data/entity-registry.yaml:
- Around line 14088-14110: The "angular-nestjs" registry entry is using hard
`dependencies` for scaffold modules (auth, user, jwt) which creates incorrect
graph edges; update the "angular-nestjs" entry to move those items from
`dependencies` into a `plannedDeps` list, remove them from `dependencies`, and
add the missing structural fields `externalDeps` and `lifecycle` consistent with
the `nextjs-react` preset pattern so the IDS loader treats them as planned
scaffold targets rather than concrete registry links.
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 185-203: The code currently stores JWTs in localStorage within the
login/logout flows (see methods login, logout and the key 'access_token'), which
encourages an XSS-sensitive default; update the implementation to use a safer
default or clearly mark it as an example: either switch to setting an HttpOnly
cookie from the server (remove client-side localStorage.setItem/removeItem usage
and rely on cookie-based auth) or, if keeping a client-side token example,
replace direct localStorage usage with a clearly documented, opt-in alternative
(e.g., a TokenStorageService abstraction used by login/logout instead of
localStorage) and add a comment in login/logout explaining the security
trade-offs. Ensure references to 'access_token', login(), and logout() are
updated accordingly.
- Line 355: Several fenced code blocks in angular-nestjs.md (the tree and prompt
example blocks that are currently just ``` ) are missing language identifiers;
update each triple-backtick fence for the tree and prompt examples to use a
plain-text language tag (e.g., ```text or ```plaintext) so markdownlint MD040 is
satisfied—search for the untagged fences labeled as the "tree" output and the
"prompt" example blocks and replace the opening ``` with ```text (or
```plaintext) for each occurrence noted in the comment.
- Around line 271-279: In canActivate, guard against missing request.user before
accessing user.role: after retrieving requiredRoles and the request via
context.switchToHttp().getRequest(), check that request.user exists and return
false if it's absent; then perform the roles check with
requiredRoles.includes(user.role). This change in canActivate (the reflector
usage and the request = context.switchToHttp().getRequest() block) prevents a
thrown error when JwtAuthGuard wasn't applied.
- Around line 90-113: The AuthModule example uses ConfigService in
JwtModule.registerAsync but does not import or register ConfigModule; update the
AuthModule to import ConfigModule and reference ConfigService for DI: add
ConfigModule (e.g., ConfigModule.forRoot() or ConfigModule) to the Module
imports array and include ConfigService in the inject array already used by
JwtModule.registerAsync so JwtModule.registerAsync can resolve the ConfigService
dependency; ensure imports include ConfigModule and that AuthModule
providers/exports remain unchanged (AuthModule, JwtModule.registerAsync,
ConfigService, ConfigModule).
- Around line 236-239: The onSubmit example uses an unsafe cast "as any";
replace it with a concrete type (e.g., define an interface LoginDto or
LoginCredentials with the expected fields) and pass that type to auth.login (for
example: const payload = this.form.getRawValue() as LoginDto; await
this.auth.login(payload)); also update the exception filter snippet to avoid "as
any" by accepting unknown, narrowing it with a type guard or instanceof checks
and mapping to a known Error/HttpException type before accessing properties;
reference the onSubmit method and the exception filter code when making these
changes so copied snippets demonstrate proper typing instead of using any.
- Around line 42-73: The shared TypeScript interfaces LoginRequestDto,
LoginResponseDto and UserDto are erased at runtime and won't work with NestJS
ValidationPipe for `@Body`() parameters; update the doc to either (a) add backend
DTO classes (e.g., LoginRequestDtoClass) that implement/extend the shared
interfaces and include class-validator decorators like `@IsString/`@IsEmail so
controllers using ValidationPipe can validate requests, or (b) explicitly state
that the shown interfaces are type-only and must be paired with separate
decorated NestJS DTO classes used in controllers; reference LoginRequestDto,
LoginResponseDto, UserDto, ValidationPipe and `@Body`() so readers know where to
apply the fix.
---
Outside diff comments:
In @.aiox-core/install-manifest.yaml:
- Around line 1-3: The manifest metadata for angular-nestjs.md has a stale file
size; regenerate the install manifest by running the generate script so size and
hash entries are recalculated: run the project script (npm run
generate:manifest) to update the entry for angular-nestjs.md and commit the
updated .aiox-core/install-manifest.yaml so the size (and hash if changed) match
the actual file.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c4801c36-0d98-4a8d-86b0-d1e8dd70fc6b
📒 Files selected for processing (4)
.aiox-core/data/entity-registry.yaml.aiox-core/data/tech-presets/angular-nestjs.md.aiox-core/install-manifest.yamlpackages/installer/src/wizard/questions.js
| angular-nestjs: | ||
| path: .aiox-core/data/tech-presets/angular-nestjs.md | ||
| layer: L3 | ||
| type: data | ||
| purpose: >- | ||
| 'Arquitetura otimizada para aplicações fullstack com Angular 21 (Signals, Standalone Components) no frontend e | ||
| NestJS (Modular, DI, Guards) no backend' | ||
| keywords: | ||
| - angular | ||
| - nestjs | ||
| - tech | ||
| - preset | ||
| usedBy: [] | ||
| dependencies: | ||
| - auth | ||
| - user | ||
| - jwt | ||
| adaptability: | ||
| score: 0.5 | ||
| constraints: [] | ||
| extensionPoints: [] | ||
| checksum: sha256:225db28dd5970a708e26dd02a88890f406d1780a013f986a0670b7c7731a1ebf | ||
| lastVerified: '2026-03-08T03:53:26.108Z' |
There was a problem hiding this comment.
Use plannedDeps here instead of hard registry dependencies.
auth, user, and jwt read like scaffolded app modules, not concrete registry entities. Unlike the sibling nextjs-react preset, this entry puts them in dependencies, and the IDS loader returns those values verbatim, so this will create misleading graph edges. It also leaves the preset structurally incomplete by omitting externalDeps and lifecycle.
Suggested fix
angular-nestjs:
path: .aiox-core/data/tech-presets/angular-nestjs.md
layer: L3
type: data
purpose: >-
'Arquitetura otimizada para aplicações fullstack com Angular 21 (Signals, Standalone Components) no frontend e
NestJS (Modular, DI, Guards) no backend'
keywords:
- angular
- nestjs
- tech
- preset
usedBy: []
- dependencies:
+ dependencies: []
+ externalDeps: []
+ plannedDeps:
- auth
- user
- jwt
+ lifecycle: experimental
adaptability:
score: 0.5
constraints: []
extensionPoints: []🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.aiox-core/data/entity-registry.yaml around lines 14088 - 14110, The
"angular-nestjs" registry entry is using hard `dependencies` for scaffold
modules (auth, user, jwt) which creates incorrect graph edges; update the
"angular-nestjs" entry to move those items from `dependencies` into a
`plannedDeps` list, remove them from `dependencies`, and add the missing
structural fields `externalDeps` and `lifecycle` consistent with the
`nextjs-react` preset pattern so the IDS loader treats them as planned scaffold
targets rather than concrete registry links.
| ```typescript | ||
| // backend/src/features/auth/auth.module.ts | ||
| import { Module } from '@nestjs/common'; | ||
| import { JwtModule } from '@nestjs/jwt'; | ||
| import { AuthController } from './auth.controller'; | ||
| import { AuthService } from './auth.service'; | ||
| import { UserRepository } from './repositories/user.repository'; | ||
| import { JwtStrategy } from './strategies/jwt.strategy'; | ||
|
|
||
| @Module({ | ||
| imports: [ | ||
| JwtModule.registerAsync({ | ||
| useFactory: (config: ConfigService) => ({ | ||
| secret: config.get('JWT_SECRET'), | ||
| signOptions: { expiresIn: '1h' }, | ||
| }), | ||
| inject: [ConfigService], | ||
| }), | ||
| ], | ||
| controllers: [AuthController], | ||
| providers: [AuthService, UserRepository, JwtStrategy], | ||
| exports: [AuthService], // Exporta apenas o que outros módulos precisam | ||
| }) | ||
| export class AuthModule {} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .aiox-core/data/tech-presets/angular-nestjs.md | head -120 | tail -35Repository: SynkraAI/aiox-core
Length of output: 1483
Add missing ConfigModule and ConfigService imports to the AuthModule example.
The example uses ConfigService on lines 102–106 without importing it or registering ConfigModule in the imports array. As written, dependency injection will fail at runtime.
Suggested fix
import { Module } from '@nestjs/common';
+import { ConfigModule, ConfigService } from '@nestjs/config';
import { JwtModule } from '@nestjs/jwt';
import { AuthController } from './auth.controller';
import { AuthService } from './auth.service';
import { UserRepository } from './repositories/user.repository';
import { JwtStrategy } from './strategies/jwt.strategy';
`@Module`({
imports: [
+ ConfigModule,
JwtModule.registerAsync({
useFactory: (config: ConfigService) => ({
secret: config.get('JWT_SECRET'),
signOptions: { expiresIn: '1h' },
}),
inject: [ConfigService],
}),
],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 90 - 113, The
AuthModule example uses ConfigService in JwtModule.registerAsync but does not
import or register ConfigModule; update the AuthModule to import ConfigModule
and reference ConfigService for DI: add ConfigModule (e.g.,
ConfigModule.forRoot() or ConfigModule) to the Module imports array and include
ConfigService in the inject array already used by JwtModule.registerAsync so
JwtModule.registerAsync can resolve the ConfigService dependency; ensure imports
include ConfigModule and that AuthModule providers/exports remain unchanged
(AuthModule, JwtModule.registerAsync, ConfigService, ConfigModule).
| async onSubmit(): Promise<void> { | ||
| if (this.form.invalid) return; | ||
| await this.auth.login(this.form.getRawValue() as any); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "angular-nestjs.md" -type f 2>/dev/null | head -20Repository: SynkraAI/aiox-core
Length of output: 110
🏁 Script executed:
wc -l ./.aiox-core/data/tech-presets/angular-nestjs.mdRepository: SynkraAI/aiox-core
Length of output: 114
🏁 Script executed:
sed -n '230,245p' ./.aiox-core/data/tech-presets/angular-nestjs.mdRepository: SynkraAI/aiox-core
Length of output: 447
🏁 Script executed:
sed -n '475,482p' ./.aiox-core/data/tech-presets/angular-nestjs.mdRepository: SynkraAI/aiox-core
Length of output: 546
🏁 Script executed:
sed -n '510,520p' ./.aiox-core/data/tech-presets/angular-nestjs.mdRepository: SynkraAI/aiox-core
Length of output: 438
Update code examples to comply with the preset's own No any rule.
Line 478 explicitly bans any in favor of unknown with type guards or explicit types, but the Angular submit flow (lines 236–239) and exception filter (lines 514–518) both use as any. Since these snippets are likely to be copied directly, they should demonstrate proper typing instead of the escape hatch they're meant to avoid.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 236 - 239, The
onSubmit example uses an unsafe cast "as any"; replace it with a concrete type
(e.g., define an interface LoginDto or LoginCredentials with the expected
fields) and pass that type to auth.login (for example: const payload =
this.form.getRawValue() as LoginDto; await this.auth.login(payload)); also
update the exception filter snippet to avoid "as any" by accepting unknown,
narrowing it with a type guard or instanceof checks and mapping to a known
Error/HttpException type before accessing properties; reference the onSubmit
method and the exception filter code when making these changes so copied
snippets demonstrate proper typing instead of using any.
| canActivate(context: ExecutionContext): boolean { | ||
| const requiredRoles = this.reflector.getAllAndOverride<string[]>('roles', [ | ||
| context.getHandler(), | ||
| context.getClass(), | ||
| ]); | ||
| if (!requiredRoles) return true; | ||
|
|
||
| const { user } = context.switchToHttp().getRequest(); | ||
| return requiredRoles.includes(user.role); |
There was a problem hiding this comment.
Guard against a missing request.user before reading role.
If someone uses @Roles() without JwtAuthGuard on a route, user.role throws and turns an auth failure into a 500. Returning false when user is absent keeps the guard safe to reuse.
Suggested doc fix
canActivate(context: ExecutionContext): boolean {
const requiredRoles = this.reflector.getAllAndOverride<string[]>('roles', [
context.getHandler(),
context.getClass(),
]);
if (!requiredRoles) return true;
const { user } = context.switchToHttp().getRequest();
- return requiredRoles.includes(user.role);
+ return !!user && requiredRoles.includes(user.role);
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| canActivate(context: ExecutionContext): boolean { | |
| const requiredRoles = this.reflector.getAllAndOverride<string[]>('roles', [ | |
| context.getHandler(), | |
| context.getClass(), | |
| ]); | |
| if (!requiredRoles) return true; | |
| const { user } = context.switchToHttp().getRequest(); | |
| return requiredRoles.includes(user.role); | |
| canActivate(context: ExecutionContext): boolean { | |
| const requiredRoles = this.reflector.getAllAndOverride<string[]>('roles', [ | |
| context.getHandler(), | |
| context.getClass(), | |
| ]); | |
| if (!requiredRoles) return true; | |
| const { user } = context.switchToHttp().getRequest(); | |
| return !!user && requiredRoles.includes(user.role); | |
| } | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 271 - 279, In
canActivate, guard against missing request.user before accessing user.role:
after retrieving requiredRoles and the request via
context.switchToHttp().getRequest(), check that request.user exists and return
false if it's absent; then perform the roles check with
requiredRoles.includes(user.role). This change in canActivate (the reflector
usage and the request = context.switchToHttp().getRequest() block) prevents a
thrown error when JwtAuthGuard wasn't applied.
|
|
||
| ## Project Structure | ||
|
|
||
| ``` |
There was a problem hiding this comment.
Add language identifiers to the remaining fenced blocks.
markdownlint is already flagging these fences with MD040. Using text/plaintext for the tree and prompt examples will keep the preset lint-clean.
Also applies to: 544-544, 635-635, 655-655
🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 355-355: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.aiox-core/data/tech-presets/angular-nestjs.md at line 355, Several fenced
code blocks in angular-nestjs.md (the tree and prompt example blocks that are
currently just ``` ) are missing language identifiers; update each
triple-backtick fence for the tree and prompt examples to use a plain-text
language tag (e.g., ```text or ```plaintext) so markdownlint MD040 is
satisfied—search for the untagged fences labeled as the "tree" output and the
"prompt" example blocks and replace the opening ``` with ```text (or
```plaintext) for each occurrence noted in the comment.
|
Solid contribution, @Silvino-Miranda! Angular 21 + NestJS is a popular enterprise stack and this preset fills a real gap in the wizard options. Implementation quality: The preset file is thorough — 711 lines covering 5 design patterns, project structure, coding standards, and testing strategy. I like that you followed the existing Specific observations:
One suggestion: The preset metadata lists Another minor thing: The Clean PR overall — good to merge once the Zod/class-validator clarification is addressed. Well done! |
github-actions
bot
added
area: agents
There was a problem hiding this comment.
♻️ Duplicate comments (6)
.aiox-core/data/tech-presets/angular-nestjs.md (5)
271-279:⚠️ Potential issue | 🟠 MajorGuard against a missing
request.userbefore readingrole.If someone uses
@Roles()withoutJwtAuthGuardon a route, accessinguser.roleon line 279 will throw and turn an auth failure into a 500 error. Returningfalsewhenuseris absent keeps the guard safe to reuse.🛡️ Suggested fix
canActivate(context: ExecutionContext): boolean { const requiredRoles = this.reflector.getAllAndOverride<string[]>('roles', [ context.getHandler(), context.getClass(), ]); if (!requiredRoles) return true; const { user } = context.switchToHttp().getRequest(); - return requiredRoles.includes(user.role); + return !!user && requiredRoles.includes(user.role); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 271 - 279, The canActivate method reads user.role without checking that request.user exists; update canActivate (and the reflector.getAllAndOverride usage) to first get the request via context.switchToHttp().getRequest(), then if request.user is missing return false instead of accessing user.role, otherwise proceed to check requiredRoles.includes(user.role) so missing JwtAuthGuard won’t cause a 500.
236-239:⚠️ Potential issue | 🟡 MinorRemove
as anyto comply with the preset's own "Noany" rule.Line 238 uses
as anyto cast the form value, which directly violates the coding standard on line 478: "Noany: Useunknown+ type guard ou tipos explícitos."Since these snippets are likely to be copied directly, they should demonstrate proper typing instead of the escape hatch they're meant to avoid.
🔧 Suggested fix
Define a concrete type for the login form:
+interface LoginFormValue { + email: string; + password: string; +} + async onSubmit(): Promise<void> { if (this.form.invalid) return; - await this.auth.login(this.form.getRawValue() as any); + const credentials = this.form.getRawValue() as LoginFormValue; + await this.auth.login(credentials); }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 236 - 239, Remove the unsafe "as any" in onSubmit; define a concrete type/interface (e.g. LoginForm { email: string; password: string; }) and ensure the FormGroup is typed or the value is asserted to that type before calling auth.login so auth.login receives a properly typed payload; update the form declaration (or use a typed local variable assigned from this.form.getRawValue()) and call auth.login(payload) instead of casting with as any in the onSubmit method.
90-113:⚠️ Potential issue | 🟠 MajorAdd missing
ConfigModuleandConfigServiceimports to theAuthModuleexample.The example uses
ConfigServiceon lines 102–106 without importing it or registeringConfigModulein the imports array. As written, dependency injection will fail at runtime.🔧 Suggested fix
import { Module } from '@nestjs/common'; +import { ConfigModule, ConfigService } from '@nestjs/config'; import { JwtModule } from '@nestjs/jwt'; import { AuthController } from './auth.controller'; import { AuthService } from './auth.service'; import { UserRepository } from './repositories/user.repository'; import { JwtStrategy } from './strategies/jwt.strategy'; `@Module`({ imports: [ + ConfigModule, JwtModule.registerAsync({ useFactory: (config: ConfigService) => ({ secret: config.get('JWT_SECRET'), signOptions: { expiresIn: '1h' }, }), inject: [ConfigService], }), ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 90 - 113, The AuthModule example uses ConfigService in JwtModule.registerAsync but never imports or registers it; fix by importing ConfigModule and ConfigService from '@nestjs/config' at the top of the file and adding ConfigModule to the `@Module` imports array alongside JwtModule.registerAsync so ConfigService is available for injection into the useFactory for JwtModule.registerAsync (update the import list and the imports: [...] entry in AuthModule).
185-203:⚠️ Potential issue | 🟠 MajorAvoid making
localStoragethe default JWT storage pattern.Using
localStoragefor auth tokens (lines 191, 200) bakes an XSS-sensitive default into a "best practices" preset. For this kind of guidance, prefer HttpOnly cookies or explicitly call out that this is a trade-off example rather than the recommended default.Consider either:
- Switch to HttpOnly cookies set from the server (remove client-side
localStorage.setItem/removeItemand rely on cookie-based auth with credentials)- Or, if keeping a client-side token example, introduce a
TokenStorageServiceabstraction and add a prominent comment explaining the security trade-offsThis prevents developers from inadvertently introducing XSS vulnerabilities by copying the example directly.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 185 - 203, The preset currently writes and removes JWTs directly via localStorage in the login() and logout() flows (localStorage.setItem / removeItem), which bakes an XSS-sensitive pattern into the example; update the example to avoid this by either (A) removing client-side token persistence in login() / logout() and relying on server-set HttpOnly cookies with fetch/http requests using credentials, or (B) introduce a TokenStorageService abstraction used by login() and logout() (e.g., TokenStorageService.setToken/getToken/removeToken) and add a prominent comment above the service and inside login()/logout() documenting the security trade-offs and recommending HttpOnly cookies for production. Ensure references to localStorage.setItem and removeItem are removed or delegated to the new service and that router.navigate calls remain unchanged.
42-73:⚠️ Potential issue | 🟠 MajorShow how shared interfaces integrate with NestJS request validation.
Pattern 1 presents shared TypeScript interfaces for the contract layer (lines 52-69). However, NestJS requires DTOs decorated with
class-validatordecorators for theValidationPipeto validate@Body()parameters at runtime. TypeScript interfaces are erased at compile time and cannot carry decorators.The comment on line 71 mentions "NestJS backend usa class-validator com o mesmo shape" but doesn't demonstrate how. To align with your validation rule (line 476), either:
Add a backend DTO example that implements or extends the shared interface and includes
class-validatordecorators:// backend/src/features/auth/dto/login-request.dto.ts import { IsEmail, IsString, MinLength } from 'class-validator'; import { LoginRequestDto as ILoginRequest } from '@shared/contracts/auth.contract'; export class LoginRequestDto implements ILoginRequest { `@IsEmail`() email: string; `@IsString`() `@MinLength`(8) password: string; }Or explicitly state that the shared interfaces are for typing only and must be paired with separate decorated NestJS DTO classes used in controllers.
This prevents readers from copying the interface directly into controllers, where validation would silently fail.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md around lines 42 - 73, The shared interfaces (e.g., LoginRequestDto, LoginResponseDto, UserDto in shared/contracts/auth.contract.ts) cannot be used for NestJS runtime validation because interfaces are erased; add a backend DTO class (e.g., a class LoginRequestDto in your backend DTO folder) that implements the shared interface and add class-validator decorators (IsEmail, IsString, MinLength, etc.) to each property, then reference that decorated DTO in controllers' `@Body`() parameters (with ValidationPipe enabled), or alternatively update the doc to explicitly state that shared interfaces are typing-only and must be paired with separate decorated NestJS DTO classes for runtime validation..aiox-core/data/entity-registry.yaml (1)
14088-14110:⚠️ Potential issue | 🟠 MajorMove scaffold modules from
dependenciestoplannedDeps, and add missing structural fields.Lines 14101-14104 currently model scaffold targets as hard dependencies, which can create incorrect registry edges. This entry is also missing
externalDeps,plannedDeps, andlifecycle.Suggested fix
angular-nestjs: path: .aiox-core/data/tech-presets/angular-nestjs.md layer: L3 type: data purpose: >- 'Arquitetura otimizada para aplicações fullstack com Angular 21 (Signals, Standalone Components) no frontend e NestJS (Modular, DI, Guards) no backend' keywords: - angular - nestjs - tech - preset usedBy: [] - dependencies: - - auth - - user - - jwt + dependencies: [] + externalDeps: [] + plannedDeps: + - auth + - user + - jwt + lifecycle: experimental adaptability: score: 0.5 constraints: [] extensionPoints: []🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/entity-registry.yaml around lines 14088 - 14110, The angular-nestjs registry entry incorrectly lists scaffold targets (auth, user, jwt) under dependencies; update the angular-nestjs block to move those module names from the dependencies field into a new plannedDeps array, and add the missing structural fields externalDeps (empty array if none) and lifecycle (e.g., an object or array consistent with other entries) so the entry includes externalDeps, plannedDeps, and lifecycle; ensure the existing adaptability and checksum/lastVerified fields remain unchanged and that the dependencies field only contains true runtime/package dependencies, not scaffolding targets.
🧹 Nitpick comments (1)
.aiox-core/data/tech-presets/angular-nestjs.md (1)
23-23: Clarify when to use Zod versus class-validator.The metadata lists Zod as a core technology (line 23), and the tech stack table mentions both class-validator for backend DTOs (line 427) and Zod for shared validation (line 428). However, all concrete examples throughout the preset use class-validator decorators (
@IsString(),@IsEmail(), etc.). This creates ambiguity for developers implementing the preset.To prevent confusion, add a brief note in the Tech Stack section or Coding Standards explaining:
- Use class-validator for NestJS DTO validation in controllers (as shown in examples)
- Use Zod for runtime schema validation in shared contracts or Angular forms where class-validator decorators cannot be used
This aligns with the reviewer's suggestion and helps developers understand the complementary roles of each library.
Also applies to: 427-428
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.aiox-core/data/tech-presets/angular-nestjs.md at line 23, Add a short clarifying note to the Tech Stack or Coding Standards section explaining when to use class-validator versus Zod: specify that class-validator should be used for NestJS DTO validation in controllers (e.g., DTOs using `@IsString`, `@IsEmail` decorators) and that Zod should be used for runtime/shared schema validation (e.g., shared contracts or Angular form/runtime validation where decorators aren’t applicable); reference both "class-validator" and "Zod" by name so readers can map the guidance to the existing tech stack entries.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.aiox-core/data/entity-registry.yaml:
- Around line 14088-14110: The angular-nestjs registry entry incorrectly lists
scaffold targets (auth, user, jwt) under dependencies; update the angular-nestjs
block to move those module names from the dependencies field into a new
plannedDeps array, and add the missing structural fields externalDeps (empty
array if none) and lifecycle (e.g., an object or array consistent with other
entries) so the entry includes externalDeps, plannedDeps, and lifecycle; ensure
the existing adaptability and checksum/lastVerified fields remain unchanged and
that the dependencies field only contains true runtime/package dependencies, not
scaffolding targets.
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Around line 271-279: The canActivate method reads user.role without checking
that request.user exists; update canActivate (and the
reflector.getAllAndOverride usage) to first get the request via
context.switchToHttp().getRequest(), then if request.user is missing return
false instead of accessing user.role, otherwise proceed to check
requiredRoles.includes(user.role) so missing JwtAuthGuard won’t cause a 500.
- Around line 236-239: Remove the unsafe "as any" in onSubmit; define a concrete
type/interface (e.g. LoginForm { email: string; password: string; }) and ensure
the FormGroup is typed or the value is asserted to that type before calling
auth.login so auth.login receives a properly typed payload; update the form
declaration (or use a typed local variable assigned from
this.form.getRawValue()) and call auth.login(payload) instead of casting with as
any in the onSubmit method.
- Around line 90-113: The AuthModule example uses ConfigService in
JwtModule.registerAsync but never imports or registers it; fix by importing
ConfigModule and ConfigService from '@nestjs/config' at the top of the file and
adding ConfigModule to the `@Module` imports array alongside
JwtModule.registerAsync so ConfigService is available for injection into the
useFactory for JwtModule.registerAsync (update the import list and the imports:
[...] entry in AuthModule).
- Around line 185-203: The preset currently writes and removes JWTs directly via
localStorage in the login() and logout() flows (localStorage.setItem /
removeItem), which bakes an XSS-sensitive pattern into the example; update the
example to avoid this by either (A) removing client-side token persistence in
login() / logout() and relying on server-set HttpOnly cookies with fetch/http
requests using credentials, or (B) introduce a TokenStorageService abstraction
used by login() and logout() (e.g.,
TokenStorageService.setToken/getToken/removeToken) and add a prominent comment
above the service and inside login()/logout() documenting the security
trade-offs and recommending HttpOnly cookies for production. Ensure references
to localStorage.setItem and removeItem are removed or delegated to the new
service and that router.navigate calls remain unchanged.
- Around line 42-73: The shared interfaces (e.g., LoginRequestDto,
LoginResponseDto, UserDto in shared/contracts/auth.contract.ts) cannot be used
for NestJS runtime validation because interfaces are erased; add a backend DTO
class (e.g., a class LoginRequestDto in your backend DTO folder) that implements
the shared interface and add class-validator decorators (IsEmail, IsString,
MinLength, etc.) to each property, then reference that decorated DTO in
controllers' `@Body`() parameters (with ValidationPipe enabled), or alternatively
update the doc to explicitly state that shared interfaces are typing-only and
must be paired with separate decorated NestJS DTO classes for runtime
validation.
---
Nitpick comments:
In @.aiox-core/data/tech-presets/angular-nestjs.md:
- Line 23: Add a short clarifying note to the Tech Stack or Coding Standards
section explaining when to use class-validator versus Zod: specify that
class-validator should be used for NestJS DTO validation in controllers (e.g.,
DTOs using `@IsString`, `@IsEmail` decorators) and that Zod should be used for
runtime/shared schema validation (e.g., shared contracts or Angular form/runtime
validation where decorators aren’t applicable); reference both "class-validator"
and "Zod" by name so readers can map the guidance to the existing tech stack
entries.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f67e35ff-defe-4e2a-82a4-cb9ab8eaeb58
📒 Files selected for processing (4)
.aiox-core/data/entity-registry.yaml.aiox-core/data/tech-presets/angular-nestjs.md.aiox-core/install-manifest.yamlpackages/installer/src/wizard/questions.js
2 participants
Pull Request
📋 Description
Add Angular 21 + NestJS as a new tech preset option in the AIOX installation wizard. This enables developers using Angular (Signals, Standalone Components) on the frontend and NestJS on the backend to get architecture patterns, project structure, coding standards, and testing strategies tailored to their stack.
🎯 AIOX Story Reference
Story ID: N/A (community contribution)
Story File: N/A
Sprint: N/A
Acceptance Criteria Addressed
New angular-nestjs option appears in the Tech Preset wizard question
Preset file follows the existing _template.md structure
Includes 5 design patterns, project structure, tech stack, coding standards, testing strategy
🔗 Related Issue
N/A
📦 Type of Change
🐛 Bug fix (non-breaking change which fixes an issue)
✨ New feature (non-breaking change which adds functionality)
💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
📚 Documentation update
🔧 Refactoring (no functional changes)
⚡ Performance improvement
🧪 Test update
🎯 Scope
Core framework (aiox-core/)
Squad (squads)
Tools (tools/)
Documentation (docs)
CI/CD (.github)
Other: ________________
📝 Changes Made
Added angular-nestjs choice to getTechPresetQuestion() in questions.js
Created angular-nestjs.md (22KB) with:
5 Design Patterns: Contract (Shared DTOs), NestJS Module, Angular Signals + Service, NestJS Guard + Decorator, Builder (Tests)
Project Structure: Monorepo layout with frontend/, backend/, shared/contracts/
Tech Stack: Angular 21, NestJS 11+, Prisma, class-validator, Angular Material, Jest, Playwright
Coding Standards: Standalone Components, Signals over BehaviorSubject, inject() over constructor DI, Guards for auth
Testing Strategy: NestJS TestingModule + Angular HttpClientTestingModule templates
Patterns to Avoid: NgModules, BehaviorSubject, logic in controllers, any types
🧪 Testing
All existing tests pass
Manual testing completed
Added tests for new functionality
Tested on multiple platforms (if applicable)
Test Results
📸 Screenshots (if applicable)
N/A — CLI wizard change (new list option added).
✅ Checklist⚠️ Skipped (missing @eslint/js dep in local env)
My code follows the project's style guidelines
I have performed a self-review of my code
I have commented my code, particularly in hard-to-understand areas
I have updated the documentation accordingly
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published
🔒 Security
I have reviewed my code for security vulnerabilities
I have not introduced any new security issues
I have checked for sensitive data exposure
🐰 CodeRabbit Review
No CRITICAL issues found
No HIGH severity issues blocking merge
All CodeRabbit suggestions addressed or documented
📊 Quality Gates
Check Status
Lint
TypeCheck ✅ Passed
Tests ✅ 24/27 passed (3 pre-existing failures)
Coverage ⏳ Pending
CodeRabbit ⏳ Pending
📖 Documentation
Updated README.md (if needed)
Updated CHANGELOG.md
Updated API documentation (if applicable)
Added code comments (if applicable)
👥 Reviewers
@SynkraAI
🚀 Deployment Notes
No migration needed. Non-breaking addition — new preset option is additive only.
Summary by CodeRabbit
New Features
Documentation
Chores