-
Notifications
You must be signed in to change notification settings - Fork 0
feat: Add diff command to compare contents of generated code #600
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Add diff command to compare contents of generated code #600
Conversation
🦋 Changeset detectedLatest commit: 79c6fdb The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughA new Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant Server
participant DiffUtils
participant Formatter
User->>CLI: baseplate diff [options]
CLI->>Server: diffProject(options)
Server->>DiffUtils: compareFiles(directory, generatedOutput, filters)
DiffUtils-->>Server: DiffSummary
Server->>Formatter: formatDiff(DiffSummary, options)
Formatter-->>Server: Formatted diff output
Server-->>CLI: Formatted diff output
CLI-->>User: Displays diff results
sequenceDiagram
participant Server
participant ProjectLoader
participant AppCompiler
participant Generator
participant Formatter
participant DiffUtils
Server->>ProjectLoader: loadProjectJson(directory)
ProjectLoader-->>Server: projectDefinition
Server->>AppCompiler: compileApplications(projectDefinition)
AppCompiler-->>Server: compiledApps
Server->>Generator: generateOutput(compiledApps)
Generator-->>Server: generatedOutput
Server->>Formatter: formatGeneratorOutput(generatedOutput)
Formatter-->>Server: formattedOutput
Server->>DiffUtils: compareFiles(directory, formattedOutput, filters)
DiffUtils-->>Server: DiffSummary
📜 Recent review detailsConfiguration used: .coderabbit.yaml ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (2)
🧰 Additional context used📓 Path-based instructions (3)`**/*.{ts,tsx}`: TypeScript with strict type checking Node 16 module resolution ...
📄 Source: CodeRabbit Inference Engine (CLAUDE.md) List of files the instruction was applied to:
`**/*`: Use kebab-case for file names
📄 Source: CodeRabbit Inference Engine (CLAUDE.md) List of files the instruction was applied to:
`{packages,plugins}/**/*.{ts,tsx}`: Use TypeScript with strict type checking ena...
📄 Source: CodeRabbit Inference Engine (.cursor/rules/code-style.mdc) List of files the instruction was applied to:
🧠 Learnings (2)📓 Common learningspackages/project-builder-server/src/diff/diff-project.ts (7)🧬 Code Graph Analysis (1)packages/project-builder-server/src/diff/diff-project.ts (15)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
🔇 Additional comments (4)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Nitpick comments (3)
packages/project-builder-server/src/sync/template-metadata-utils.ts (1)
4-9: Improve JSDoc documentation.Consider adding more detailed documentation about the whitelist format and behavior.
/** * Creates template metadata options based on project definition settings. * * @param projectJson - The project definition containing template extractor settings - * @returns Template metadata options or undefined if not enabled + * @returns Template metadata options or undefined if writeMetadata is disabled. + * The options include regex-based filtering using patterns from fileIdRegexWhitelist, + * where each pattern is tested against the format "generatorName:fileId". */packages/project-builder-server/src/diff/diff-utils.ts (1)
144-146: Acknowledge the TODO for deleted file detection.The TODO comment correctly identifies missing functionality for detecting files that exist in the working directory but not in generated output. This is a reasonable limitation for the initial implementation.
Would you like me to help implement the deleted file detection functionality, or should this be tracked as a separate issue?
packages/project-builder-server/src/diff/diff-project.ts (1)
30-32: Use absolute paths for imports instead of relative paths.According to the coding guidelines, imports should use absolute paths via tsconfig paths for consistency.
-import { createTemplateMetadataOptions } from '../sync/template-metadata-utils.js'; -import { compareFiles } from './diff-utils.js'; -import { formatCompactDiff, formatUnifiedDiff } from './formatters.js'; +import { createTemplateMetadataOptions } from '#src/sync/template-metadata-utils.js'; +import { compareFiles } from '#src/diff/diff-utils.js'; +import { formatCompactDiff, formatUnifiedDiff } from '#src/diff/formatters.js';
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (19)
.changeset/add-diff-command.md(1 hunks)package.json(1 hunks)packages/project-builder-cli/src/commands/diff.ts(1 hunks)packages/project-builder-cli/src/index.ts(2 hunks)packages/project-builder-server/package.json(1 hunks)packages/project-builder-server/src/diff/diff-project.ts(1 hunks)packages/project-builder-server/src/diff/diff-utils.ts(1 hunks)packages/project-builder-server/src/diff/diff-utils.unit.test.ts(1 hunks)packages/project-builder-server/src/diff/formatters.ts(1 hunks)packages/project-builder-server/src/diff/formatters.unit.test.ts(1 hunks)packages/project-builder-server/src/diff/index.ts(1 hunks)packages/project-builder-server/src/diff/types.ts(1 hunks)packages/project-builder-server/src/index.ts(1 hunks)packages/project-builder-server/src/sync/build-project.ts(2 hunks)packages/project-builder-server/src/sync/template-metadata-utils.ts(1 hunks)packages/sync/src/output/format-generator-output.ts(1 hunks)packages/sync/src/output/format-generator-output.unit.test.ts(1 hunks)packages/sync/src/output/index.ts(1 hunks)packages/sync/src/output/prepare-generator-files/prepare-generator-file.ts(5 hunks)
🧰 Additional context used
📓 Path-based instructions (11)
`**/*.{ts,tsx}`: TypeScript with strict type checking Node 16 module resolution ...
**/*.{ts,tsx}: TypeScript with strict type checking
Node 16 module resolution - include file extensions in imports (.js)
Sort imports by group: external libs first, then local imports
Use camelCase for variables/functions, PascalCase for types/classes
Always include return types on top-level functions including React components (React.ReactElement)
Include absolute paths in import statements via tsconfig paths (@src/is the alias forsrc/)
Order functions such that functions are placed below the variables/functions they use
If a particular interface or type is not exported, change the file so it is exported
Prefer using nullish coalescing operator (??) instead of logical or (||)
Use console.info/warn/error instead of console.log
Always use.jsextensions in imports, even for TypeScript files
Specify explicit return types on all functions
📄 Source: CodeRabbit Inference Engine (CLAUDE.md)
List of files the instruction was applied to:
packages/project-builder-cli/src/index.tspackages/project-builder-server/src/diff/index.tspackages/project-builder-server/src/index.tspackages/sync/src/output/index.tspackages/project-builder-server/src/sync/build-project.tspackages/project-builder-cli/src/commands/diff.tspackages/project-builder-server/src/sync/template-metadata-utils.tspackages/project-builder-server/src/diff/types.tspackages/sync/src/output/prepare-generator-files/prepare-generator-file.tspackages/sync/src/output/format-generator-output.unit.test.tspackages/project-builder-server/src/diff/diff-utils.unit.test.tspackages/project-builder-server/src/diff/diff-utils.tspackages/project-builder-server/src/diff/formatters.unit.test.tspackages/sync/src/output/format-generator-output.tspackages/project-builder-server/src/diff/formatters.tspackages/project-builder-server/src/diff/diff-project.ts
`**/*`: Use kebab-case for file names
**/*: Use kebab-case for file names
📄 Source: CodeRabbit Inference Engine (CLAUDE.md)
List of files the instruction was applied to:
packages/project-builder-cli/src/index.tspackages/project-builder-server/src/diff/index.tspackages/project-builder-server/src/index.tspackages/project-builder-server/package.jsonpackages/sync/src/output/index.tspackages/project-builder-server/src/sync/build-project.tspackages/project-builder-cli/src/commands/diff.tspackage.jsonpackages/project-builder-server/src/sync/template-metadata-utils.tspackages/project-builder-server/src/diff/types.tspackages/sync/src/output/prepare-generator-files/prepare-generator-file.tspackages/sync/src/output/format-generator-output.unit.test.tspackages/project-builder-server/src/diff/diff-utils.unit.test.tspackages/project-builder-server/src/diff/diff-utils.tspackages/project-builder-server/src/diff/formatters.unit.test.tspackages/sync/src/output/format-generator-output.tspackages/project-builder-server/src/diff/formatters.tspackages/project-builder-server/src/diff/diff-project.ts
`**/index.{ts,tsx}`: Prefer barrel exports e.g. `export * from './foo.js'` instead of individual named exports
**/index.{ts,tsx}: Prefer barrel exports e.g.export * from './foo.js'instead of individual named exports
📄 Source: CodeRabbit Inference Engine (CLAUDE.md)
List of files the instruction was applied to:
packages/project-builder-cli/src/index.tspackages/project-builder-server/src/diff/index.tspackages/project-builder-server/src/index.tspackages/sync/src/output/index.ts
`{packages,plugins}/**/*.{ts,tsx}`: Use TypeScript with strict type checking ena...
{packages,plugins}/**/*.{ts,tsx}: Use TypeScript with strict type checking enabled
All functions (excluding one-liner arrow functions) require explicit return types
Use camelCase for variables and functions
Use PascalCase for types and classes
Prefer functional programming patterns
Extract repeated components into distinct functions or components where applicable
📄 Source: CodeRabbit Inference Engine (.cursor/rules/code-style.mdc)
List of files the instruction was applied to:
packages/project-builder-cli/src/index.tspackages/project-builder-server/src/diff/index.tspackages/project-builder-server/src/index.tspackages/sync/src/output/index.tspackages/project-builder-server/src/sync/build-project.tspackages/project-builder-cli/src/commands/diff.tspackages/project-builder-server/src/sync/template-metadata-utils.tspackages/project-builder-server/src/diff/types.tspackages/sync/src/output/prepare-generator-files/prepare-generator-file.tspackages/sync/src/output/format-generator-output.unit.test.tspackages/project-builder-server/src/diff/diff-utils.unit.test.tspackages/project-builder-server/src/diff/diff-utils.tspackages/project-builder-server/src/diff/formatters.unit.test.tspackages/sync/src/output/format-generator-output.tspackages/project-builder-server/src/diff/formatters.tspackages/project-builder-server/src/diff/diff-project.ts
`.changeset/*.md`: If you are adding a new feature or changing an existing feature, add a new Changeset in the `.changeset/` directory
.changeset/*.md: If you are adding a new feature or changing an existing feature, add a new Changeset in the.changeset/directory
📄 Source: CodeRabbit Inference Engine (CLAUDE.md)
List of files the instruction was applied to:
.changeset/add-diff-command.md
`**/*.{unit,int}.test.ts`: Unit tests use `.unit.test.ts` suffix, integration te...
**/*.{unit,int}.test.ts: Unit tests use.unit.test.tssuffix, integration tests use.int.test.ts
Collocate tests with source files using.unit.test.tsor.int.test.tssuffixes
📄 Source: CodeRabbit Inference Engine (CLAUDE.md)
List of files the instruction was applied to:
packages/sync/src/output/format-generator-output.unit.test.tspackages/project-builder-server/src/diff/diff-utils.unit.test.tspackages/project-builder-server/src/diff/formatters.unit.test.ts
`**/*.test.ts`: Always import vitest globals explicitly (describe, it, expect) U...
**/*.test.ts: Always import vitest globals explicitly (describe, it, expect)
Use descriptive test names that explain what is being tested
Structure tests with clear setup, execution, and verification phases (Arrange-Act-Assert)
Always mock external API calls and file system operations in tests
Extract common setup code into test helpers
Include tests for error conditions and edge cases
Each test should be independent and not rely on others
Always reset mocks and clean up resources in afterEach
Leverage TypeScript for type-safe mocking in tests
Focus on testing public methods and behaviors, not implementation details
Each test should verify one specific behavior
Import test functions from 'vitest' (no globals)
📄 Source: CodeRabbit Inference Engine (CLAUDE.md)
List of files the instruction was applied to:
packages/sync/src/output/format-generator-output.unit.test.tspackages/project-builder-server/src/diff/diff-utils.unit.test.tspackages/project-builder-server/src/diff/formatters.unit.test.ts
`{packages,plugins}/**/*.unit.test.ts`: Unit tests use `.unit.test.ts` suffix
{packages,plugins}/**/*.unit.test.ts: Unit tests use.unit.test.tssuffix
📄 Source: CodeRabbit Inference Engine (.cursor/rules/code-style.mdc)
List of files the instruction was applied to:
packages/sync/src/output/format-generator-output.unit.test.tspackages/project-builder-server/src/diff/diff-utils.unit.test.tspackages/project-builder-server/src/diff/formatters.unit.test.ts
`{packages,plugins}/**/*.{unit,int}.test.ts`: Always import vitest globals explicitly (describe, it, expect)
{packages,plugins}/**/*.{unit,int}.test.ts: Always import vitest globals explicitly (describe, it, expect)
📄 Source: CodeRabbit Inference Engine (.cursor/rules/code-style.mdc)
List of files the instruction was applied to:
packages/sync/src/output/format-generator-output.unit.test.tspackages/project-builder-server/src/diff/diff-utils.unit.test.tspackages/project-builder-server/src/diff/formatters.unit.test.ts
`**/*.unit.test.{ts,tsx}`: Unit tests are colocated with source files using `.unit.test.ts` suffix
**/*.unit.test.{ts,tsx}: Unit tests are colocated with source files using.unit.test.tssuffix
📄 Source: CodeRabbit Inference Engine (.cursor/rules/tests.mdc)
List of files the instruction was applied to:
packages/sync/src/output/format-generator-output.unit.test.tspackages/project-builder-server/src/diff/diff-utils.unit.test.tspackages/project-builder-server/src/diff/formatters.unit.test.ts
`**/*.test.{ts,tsx}`: For file system operations in tests, use memfs and mock 'node:fs' and 'node:fs/promises' with vi.mock
**/*.test.{ts,tsx}: For file system operations in tests, use memfs and mock 'node:fs' and 'node:fs/promises' with vi.mock
📄 Source: CodeRabbit Inference Engine (.cursor/rules/tests.mdc)
List of files the instruction was applied to:
packages/sync/src/output/format-generator-output.unit.test.tspackages/project-builder-server/src/diff/diff-utils.unit.test.tspackages/project-builder-server/src/diff/formatters.unit.test.ts
🧠 Learnings (19)
📓 Common learnings
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.tsx : Use ShadCN-based components from `@baseplate-dev/ui-components` instead of creating custom ones
packages/project-builder-cli/src/index.ts (2)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Node 16 module resolution - include file extensions in imports (`.js`)
Learnt from: kingston
PR: halfdomelabs/baseplate#428
File: packages/project-builder-server/src/sync/index.ts:5-5
Timestamp: 2025-01-23T09:12:46.178Z
Learning: Avoid importing directly from 'dist' directories. Instead, expose functionality through the package's public API and import from the main package entry point.
packages/project-builder-server/src/diff/index.ts (13)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/index.{ts,tsx} : Prefer barrel exports e.g. `export * from './foo.js'` instead of individual named exports
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Node 16 module resolution - include file extensions in imports (`.js`)
Learnt from: kingston
PR: halfdomelabs/baseplate#428
File: packages/project-builder-server/src/sync/index.ts:5-5
Timestamp: 2025-01-23T09:12:46.178Z
Learning: Avoid importing directly from 'dist' directories. Instead, expose functionality through the package's public API and import from the main package entry point.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : If a particular interface or type is not exported, change the file so it is exported
Learnt from: kingston
PR: halfdomelabs/baseplate#571
File: packages/core-generators/src/renderers/extractor/plugins/typed-templates-file.ts:102-106
Timestamp: 2025-06-11T18:31:22.247Z
Learning: For `templateExtractorBarrelExportPlugin.addGeneratedBarrelExport`, the generated barrel exports are written into `generated/index.ts`, therefore the `moduleSpecifier` must be specified relative to that file (e.g., `./typed-templates.js`), not the project root.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Extract repeated components into distinct functions or components where applicable
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Include absolute paths in import statements via tsconfig paths (`@src/` is the alias for `src/`)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{unit,int}.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Sort imports by group: external libs first, then local imports
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Import test functions from 'vitest' (no globals)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Prefer functional programming patterns
packages/project-builder-server/src/index.ts (13)
Learnt from: kingston
PR: halfdomelabs/baseplate#428
File: packages/project-builder-server/src/sync/index.ts:5-5
Timestamp: 2025-01-23T09:12:46.178Z
Learning: Avoid importing directly from 'dist' directories. Instead, expose functionality through the package's public API and import from the main package entry point.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : If a particular interface or type is not exported, change the file so it is exported
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/index.{ts,tsx} : Prefer barrel exports e.g. `export * from './foo.js'` instead of individual named exports
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Node 16 module resolution - include file extensions in imports (`.js`)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Include absolute paths in import statements via tsconfig paths (`@src/` is the alias for `src/`)
Learnt from: kingston
PR: halfdomelabs/baseplate#571
File: packages/core-generators/src/renderers/extractor/plugins/typed-templates-file.ts:102-106
Timestamp: 2025-06-11T18:31:22.247Z
Learning: For `templateExtractorBarrelExportPlugin.addGeneratedBarrelExport`, the generated barrel exports are written into `generated/index.ts`, therefore the `moduleSpecifier` must be specified relative to that file (e.g., `./typed-templates.js`), not the project root.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Extract repeated components into distinct functions or components where applicable
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{unit,int}.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:70-79
Timestamp: 2025-05-08T12:56:11.723Z
Learning: In the check-changesets.ts script for monorepo validation, `npm pack ${pkg.name}@latest` is intentionally used to pack the most recently published version (not local changes) for comparison purposes to determine if changes require new changesets.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 22.0.0 and later versions include both `glob` and `globSync` functionality in the core `node:fs` module, making `import { promises as fs, globSync } from 'node:fs';` valid syntax.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Import test functions from 'vitest' (no globals)
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 20.12.0 and above include `globSync` in the core `node:fs` module, so `import { promises as fs, globSync } from 'node:fs';` is valid syntax in projects using these Node.js versions.
packages/project-builder-server/package.json (9)
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:70-79
Timestamp: 2025-05-08T12:56:11.723Z
Learning: In the check-changesets.ts script for monorepo validation, `npm pack ${pkg.name}@latest` is intentionally used to pack the most recently published version (not local changes) for comparison purposes to determine if changes require new changesets.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: kingston
PR: halfdomelabs/baseplate#562
File: plugins/plugin-auth/package.json:32-36
Timestamp: 2025-06-03T09:11:29.651Z
Learning: With TypeScript project references, TypeScript compilation is watched from the root level using "watch:tsc:root" script, so individual packages no longer need to include their "tsc:watch" scripts in their local "watch" commands. The local "tsc:watch" scripts are renamed from "watch:tsc" but are not meant to be run as part of the package's watch command since TypeScript watching is handled centrally at the workspace root.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:111-124
Timestamp: 2025-05-08T12:56:23.394Z
Learning: Node.js 22.0.0 and later versions provide native glob functionality via `fs.glob` method in the `node:fs/promises` module, allowing pattern matching without requiring external dependencies.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:111-124
Timestamp: 2025-05-08T12:56:23.394Z
Learning: Node.js 22.0.0 and later versions provide native glob functionality via `fs.glob` and `fs.globSync` methods in the `node:fs` module, allowing pattern matching without external dependencies.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 20.12.0 and above include `globSync` in the core `node:fs` module, so `import { promises as fs, globSync } from 'node:fs';` is valid syntax in projects using these Node.js versions.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 22.0.0 and later versions include both `glob` and `globSync` functionality in the core `node:fs` module, making `import { promises as fs, globSync } from 'node:fs';` valid syntax.
Learnt from: kingston
PR: halfdomelabs/baseplate#510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: When testing file operations in this codebase, the pattern is to use Vitest automocks for 'node:fs' and 'node:fs/promises' (without explicit implementation replacement) while populating a virtual filesystem with vol.fromJSON() from memfs. File operations in tests are performed directly via vol.promises methods.
Learnt from: kingston
PR: halfdomelabs/baseplate#510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: In this codebase, when testing file operations, Vitest's automocks for 'node:fs' and 'node:fs/promises' are used in conjunction with memfs, but without replacing the mock implementation explicitly in each test file. The virtual filesystem is populated using vol.fromJSON or similar methods, which works seamlessly with the automocks.
packages/sync/src/output/index.ts (16)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : If a particular interface or type is not exported, change the file so it is exported
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/index.{ts,tsx} : Prefer barrel exports e.g. `export * from './foo.js'` instead of individual named exports
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Node 16 module resolution - include file extensions in imports (`.js`)
Learnt from: kingston
PR: halfdomelabs/baseplate#571
File: packages/core-generators/src/renderers/extractor/plugins/typed-templates-file.ts:102-106
Timestamp: 2025-06-11T18:31:22.247Z
Learning: For `templateExtractorBarrelExportPlugin.addGeneratedBarrelExport`, the generated barrel exports are written into `generated/index.ts`, therefore the `moduleSpecifier` must be specified relative to that file (e.g., `./typed-templates.js`), not the project root.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 20.12.0 and above include `globSync` in the core `node:fs` module, so `import { promises as fs, globSync } from 'node:fs';` is valid syntax in projects using these Node.js versions.
Learnt from: kingston
PR: halfdomelabs/baseplate#428
File: packages/project-builder-server/src/sync/index.ts:5-5
Timestamp: 2025-01-23T09:12:46.178Z
Learning: Avoid importing directly from 'dist' directories. Instead, expose functionality through the package's public API and import from the main package entry point.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 22.0.0 and later versions include both `glob` and `globSync` functionality in the core `node:fs` module, making `import { promises as fs, globSync } from 'node:fs';` valid syntax.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{unit,int}.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Include absolute paths in import statements via tsconfig paths (`@src/` is the alias for `src/`)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Sort imports by group: external libs first, then local imports
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Import test functions from 'vitest' (no globals)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Extract common setup code into test helpers
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to src/tests/**/*.{ts,tsx} : Test helpers are located in `src/tests/` directory
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to src/tests/**/*.{ts,tsx} : Test helpers are located in `src/tests/` directory
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Always import vitest globals explicitly (describe, it, expect)
packages/project-builder-server/src/sync/build-project.ts (11)
Learnt from: kingston
PR: halfdomelabs/baseplate#571
File: packages/core-generators/src/renderers/extractor/plugins/typed-templates-file.ts:102-106
Timestamp: 2025-06-11T18:31:22.247Z
Learning: For `templateExtractorBarrelExportPlugin.addGeneratedBarrelExport`, the generated barrel exports are written into `generated/index.ts`, therefore the `moduleSpecifier` must be specified relative to that file (e.g., `./typed-templates.js`), not the project root.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Extract repeated components into distinct functions or components where applicable
Learnt from: kingston
PR: halfdomelabs/baseplate#592
File: plugins/plugin-auth/src/auth0/generators/react/auth0-hooks/templates/src/hooks/use-required-user-id.ts:1-2
Timestamp: 2025-07-07T18:24:17.522Z
Learning: Files under templates/** directories can use `// @ts-nocheck` because they are templates meant for code generation, not direct type checking.
Learnt from: kingston
PR: halfdomelabs/baseplate#562
File: plugins/plugin-auth/package.json:32-36
Timestamp: 2025-06-03T09:11:29.651Z
Learning: With TypeScript project references, TypeScript compilation is watched from the root level using "watch:tsc:root" script, so individual packages no longer need to include their "tsc:watch" scripts in their local "watch" commands. The local "tsc:watch" scripts are renamed from "watch:tsc" but are not meant to be run as part of the package's watch command since TypeScript watching is handled centrally at the workspace root.
Learnt from: kingston
PR: halfdomelabs/baseplate#527
File: packages/project-builder-server/src/sync/build-project.ts:106-116
Timestamp: 2025-05-06T09:56:52.789Z
Learning: In the buildProject function, the startedAt timestamp should be set to the current date at the beginning of the function to accurately track when the build process started.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Prefer functional programming patterns
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: kingston
PR: halfdomelabs/baseplate#521
File: packages/react-generators/src/generators/admin/admin-crud-list/admin-crud-list.generator.ts:163-166
Timestamp: 2025-05-05T06:37:51.001Z
Learning: For certain templates in the codebase, the `importMapProviders` property is not explicitly required as the template extractor will automatically determine and infer the necessary import map providers.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 20.12.0 and above include `globSync` in the core `node:fs` module, so `import { promises as fs, globSync } from 'node:fs';` is valid syntax in projects using these Node.js versions.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 22.0.0 and later versions include both `glob` and `globSync` functionality in the core `node:fs` module, making `import { promises as fs, globSync } from 'node:fs';` valid syntax.
Learnt from: kingston
PR: halfdomelabs/baseplate#511
File: packages/project-builder-server/src/service/builder-service.ts:158-183
Timestamp: 2025-04-23T16:39:07.742Z
Learning: The `writeMetadata` method in the `SyncMetadataController` class returns void and is synchronous, not a Promise.
package.json (3)
Learnt from: kingston
PR: halfdomelabs/baseplate#562
File: plugins/plugin-auth/package.json:32-36
Timestamp: 2025-06-03T09:11:29.651Z
Learning: With TypeScript project references, TypeScript compilation is watched from the root level using "watch:tsc:root" script, so individual packages no longer need to include their "tsc:watch" scripts in their local "watch" commands. The local "tsc:watch" scripts are renamed from "watch:tsc" but are not meant to be run as part of the package's watch command since TypeScript watching is handled centrally at the workspace root.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:70-79
Timestamp: 2025-05-08T12:56:11.723Z
Learning: In the check-changesets.ts script for monorepo validation, `npm pack ${pkg.name}@latest` is intentionally used to pack the most recently published version (not local changes) for comparison purposes to determine if changes require new changesets.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
packages/project-builder-server/src/sync/template-metadata-utils.ts (3)
Learnt from: kingston
PR: halfdomelabs/baseplate#571
File: packages/core-generators/src/renderers/extractor/plugins/typed-templates-file.ts:102-106
Timestamp: 2025-06-11T18:31:22.247Z
Learning: For `templateExtractorBarrelExportPlugin.addGeneratedBarrelExport`, the generated barrel exports are written into `generated/index.ts`, therefore the `moduleSpecifier` must be specified relative to that file (e.g., `./typed-templates.js`), not the project root.
Learnt from: kingston
PR: halfdomelabs/baseplate#592
File: plugins/plugin-auth/src/auth0/generators/react/auth0-hooks/templates/src/hooks/use-required-user-id.ts:1-2
Timestamp: 2025-07-07T18:24:17.522Z
Learning: Files under templates/** directories can use `// @ts-nocheck` because they are templates meant for code generation, not direct type checking.
Learnt from: kingston
PR: halfdomelabs/baseplate#521
File: plugins/baseplate-plugin-storage/src/generators/react/upload-components/upload-components.generator.ts:108-112
Timestamp: 2025-05-05T06:37:43.106Z
Learning: The template extractor in the baseplate codebase can automatically infer and determine the necessary import map providers for certain templates, making explicit specification of importMapProviders unnecessary in those cases.
.changeset/add-diff-command.md (1)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
packages/project-builder-server/src/diff/types.ts (10)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : If a particular interface or type is not exported, change the file so it is exported
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : TypeScript with strict type checking
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Use TypeScript with strict type checking enabled
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Node 16 module resolution - include file extensions in imports (`.js`)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{unit,int}.test.ts : Unit tests use `.unit.test.ts` suffix, integration tests use `.int.test.ts`
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Use PascalCase for types and classes
Learnt from: kingston
PR: halfdomelabs/baseplate#592
File: plugins/plugin-auth/src/auth0/generators/react/auth0-hooks/templates/src/hooks/use-required-user-id.ts:1-2
Timestamp: 2025-07-07T18:24:17.522Z
Learning: Files under templates/** directories can use `// @ts-nocheck` because they are templates meant for code generation, not direct type checking.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Specify explicit return types on all functions
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Extract repeated components into distinct functions or components where applicable
packages/sync/src/output/prepare-generator-files/prepare-generator-file.ts (8)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : If a particular interface or type is not exported, change the file so it is exported
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Extract repeated components into distinct functions or components where applicable
Learnt from: kingston
PR: halfdomelabs/baseplate#571
File: packages/core-generators/src/renderers/extractor/plugins/typed-templates-file.ts:102-106
Timestamp: 2025-06-11T18:31:22.247Z
Learning: For `templateExtractorBarrelExportPlugin.addGeneratedBarrelExport`, the generated barrel exports are written into `generated/index.ts`, therefore the `moduleSpecifier` must be specified relative to that file (e.g., `./typed-templates.js`), not the project root.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Use camelCase for variables and functions
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Prefer functional programming patterns
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 20.12.0 and above include `globSync` in the core `node:fs` module, so `import { promises as fs, globSync } from 'node:fs';` is valid syntax in projects using these Node.js versions.
Learnt from: kingston
PR: halfdomelabs/baseplate#521
File: packages/react-generators/src/generators/admin/admin-components/admin-components.generator.ts:55-61
Timestamp: 2025-05-05T06:35:13.300Z
Learning: In generators, paths should be merged with forward slashes (/) only since JavaScript generated files use POSIX style separators. The system handles conversion to Windows style separators at later stages when writing out files.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 22.0.0 and later versions include both `glob` and `globSync` functionality in the core `node:fs` module, making `import { promises as fs, globSync } from 'node:fs';` valid syntax.
packages/sync/src/output/format-generator-output.unit.test.ts (17)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.unit.test.ts : Unit tests use `.unit.test.ts` suffix
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to **/*.unit.test.{ts,tsx} : Unit tests are colocated with source files using `.unit.test.ts` suffix
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{unit,int}.test.ts : Collocate tests with source files using `.unit.test.ts` or `.int.test.ts` suffixes
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{unit,int}.test.ts : Unit tests use `.unit.test.ts` suffix, integration tests use `.int.test.ts`
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Each test should verify one specific behavior
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Colocate tests with implementation files, e.g. for `./utils.ts`, add the test to `./utils.unit.test.ts`
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{unit,int}.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Leverage TypeScript for type-safe mocking in tests
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Include tests for error conditions and edge cases
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to **/*.test.{ts,tsx} : For file system operations in tests, use memfs and mock 'node:fs' and 'node:fs/promises' with vi.mock
Learnt from: kingston
PR: halfdomelabs/baseplate#510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: When testing file operations in this codebase, the pattern is to use Vitest automocks for 'node:fs' and 'node:fs/promises' (without explicit implementation replacement) while populating a virtual filesystem with vol.fromJSON() from memfs. File operations in tests are performed directly via vol.promises methods.
Learnt from: kingston
PR: halfdomelabs/baseplate#510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: In this codebase, when testing file operations, Vitest's automocks for 'node:fs' and 'node:fs/promises' are used in conjunction with memfs, but without replacing the mock implementation explicitly in each test file. The virtual filesystem is populated using vol.fromJSON or similar methods, which works seamlessly with the automocks.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: kingston
PR: halfdomelabs/baseplate#510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: In the project-builder-server test suite, Vitest automocks for 'node:fs' and 'node:fs/promises' are already configured to use memfs without needing explicit implementation replacement in each test file.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Import test functions from 'vitest' (no globals)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Structure tests with clear setup, execution, and verification phases (Arrange-Act-Assert)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Always mock external API calls and file system operations in tests
packages/project-builder-server/src/diff/diff-utils.unit.test.ts (15)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Colocate tests with implementation files, e.g. for `./utils.ts`, add the test to `./utils.unit.test.ts`
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.unit.test.ts : Unit tests use `.unit.test.ts` suffix
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{unit,int}.test.ts : Collocate tests with source files using `.unit.test.ts` or `.int.test.ts` suffixes
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to **/*.unit.test.{ts,tsx} : Unit tests are colocated with source files using `.unit.test.ts` suffix
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{unit,int}.test.ts : Unit tests use `.unit.test.ts` suffix, integration tests use `.int.test.ts`
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Include tests for error conditions and edge cases
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{unit,int}.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to **/*.test.{ts,tsx} : For file system operations in tests, use memfs and mock 'node:fs' and 'node:fs/promises' with vi.mock
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to src/tests/**/*.{ts,tsx} : Test helpers are located in `src/tests/` directory
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to src/tests/**/*.{ts,tsx} : Test helpers are located in `src/tests/` directory
Learnt from: kingston
PR: halfdomelabs/baseplate#510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: When testing file operations in this codebase, the pattern is to use Vitest automocks for 'node:fs' and 'node:fs/promises' (without explicit implementation replacement) while populating a virtual filesystem with vol.fromJSON() from memfs. File operations in tests are performed directly via vol.promises methods.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: kingston
PR: halfdomelabs/baseplate#510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: In this codebase, when testing file operations, Vitest's automocks for 'node:fs' and 'node:fs/promises' are used in conjunction with memfs, but without replacing the mock implementation explicitly in each test file. The virtual filesystem is populated using vol.fromJSON or similar methods, which works seamlessly with the automocks.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Import test functions from 'vitest' (no globals)
Learnt from: kingston
PR: halfdomelabs/baseplate#510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: In the project-builder-server test suite, Vitest automocks for 'node:fs' and 'node:fs/promises' are already configured to use memfs without needing explicit implementation replacement in each test file.
packages/project-builder-server/src/diff/diff-utils.ts (11)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Node 16 module resolution - include file extensions in imports (`.js`)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Extract repeated components into distinct functions or components where applicable
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 20.12.0 and above include `globSync` in the core `node:fs` module, so `import { promises as fs, globSync } from 'node:fs';` is valid syntax in projects using these Node.js versions.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{unit,int}.test.ts : Collocate tests with source files using `.unit.test.ts` or `.int.test.ts` suffixes
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:10-13
Timestamp: 2025-05-08T12:56:59.222Z
Learning: Node.js 22.0.0 and later versions include both `glob` and `globSync` functionality in the core `node:fs` module, making `import { promises as fs, globSync } from 'node:fs';` valid syntax.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Colocate tests with implementation files, e.g. for `./utils.ts`, add the test to `./utils.unit.test.ts`
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to **/*.unit.test.{ts,tsx} : Unit tests are colocated with source files using `.unit.test.ts` suffix
Learnt from: kingston
PR: halfdomelabs/baseplate#571
File: packages/core-generators/src/renderers/extractor/plugins/typed-templates-file.ts:102-106
Timestamp: 2025-06-11T18:31:22.247Z
Learning: For `templateExtractorBarrelExportPlugin.addGeneratedBarrelExport`, the generated barrel exports are written into `generated/index.ts`, therefore the `moduleSpecifier` must be specified relative to that file (e.g., `./typed-templates.js`), not the project root.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:111-124
Timestamp: 2025-05-08T12:56:23.394Z
Learning: Node.js 22.0.0 and later versions provide native glob functionality via `fs.glob` method in the `node:fs/promises` module, allowing pattern matching without requiring external dependencies.
Learnt from: kingston
PR: halfdomelabs/baseplate#592
File: plugins/plugin-auth/src/auth0/generators/react/auth0-hooks/templates/src/hooks/use-required-user-id.ts:1-2
Timestamp: 2025-07-07T18:24:17.522Z
Learning: Files under templates/** directories can use `// @ts-nocheck` because they are templates meant for code generation, not direct type checking.
packages/project-builder-server/src/diff/formatters.unit.test.ts (15)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.unit.test.ts : Unit tests use `.unit.test.ts` suffix
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{unit,int}.test.ts : Collocate tests with source files using `.unit.test.ts` or `.int.test.ts` suffixes
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{unit,int}.test.ts : Unit tests use `.unit.test.ts` suffix, integration tests use `.int.test.ts`
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-06-30T11:52:28.745Z
Learning: Applies to **/*.unit.test.{ts,tsx} : Unit tests are colocated with source files using `.unit.test.ts` suffix
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{unit,int}.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Colocate tests with implementation files, e.g. for `./utils.ts`, add the test to `./utils.unit.test.ts`
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Use descriptive test names that explain what is being tested
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Structure tests with clear setup, execution, and verification phases (Arrange-Act-Assert)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Include tests for error conditions and edge cases
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.int.test.ts : Integration tests use `.int.test.ts` suffix
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Always import vitest globals explicitly (describe, it, expect)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Import test functions from 'vitest' (no globals)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Each test should verify one specific behavior
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.test.ts : Extract common setup code into test helpers
Learnt from: kingston
PR: halfdomelabs/baseplate#510
File: packages/project-builder-server/src/sync/conflict-file-monitor.test.ts:19-24
Timestamp: 2025-04-23T06:44:30.952Z
Learning: When testing file operations in this codebase, the pattern is to use Vitest automocks for 'node:fs' and 'node:fs/promises' (without explicit implementation replacement) while populating a virtual filesystem with vol.fromJSON() from memfs. File operations in tests are performed directly via vol.promises methods.
packages/sync/src/output/format-generator-output.ts (2)
Learnt from: kingston
PR: halfdomelabs/baseplate#571
File: packages/core-generators/src/renderers/extractor/plugins/typed-templates-file.ts:102-106
Timestamp: 2025-06-11T18:31:22.247Z
Learning: For `templateExtractorBarrelExportPlugin.addGeneratedBarrelExport`, the generated barrel exports are written into `generated/index.ts`, therefore the `moduleSpecifier` must be specified relative to that file (e.g., `./typed-templates.js`), not the project root.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : If a particular interface or type is not exported, change the file so it is exported
packages/project-builder-server/src/diff/formatters.ts (2)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Extract repeated components into distinct functions or components where applicable
packages/project-builder-server/src/diff/diff-project.ts (8)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/ui-rules.mdc:0-0
Timestamp: 2025-06-30T11:52:33.318Z
Learning: Applies to *.{tsx},packages/project-builder-web/**,packages/ui-components/** : We use a rough analog of ShadCN components that can be imported from @baseplate-dev/ui-components
Learnt from: kingston
PR: halfdomelabs/baseplate#571
File: packages/core-generators/src/renderers/extractor/plugins/typed-templates-file.ts:102-106
Timestamp: 2025-06-11T18:31:22.247Z
Learning: For `templateExtractorBarrelExportPlugin.addGeneratedBarrelExport`, the generated barrel exports are written into `generated/index.ts`, therefore the `moduleSpecifier` must be specified relative to that file (e.g., `./typed-templates.js`), not the project root.
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Node 16 module resolution - include file extensions in imports (`.js`)
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: .cursor/rules/code-style.mdc:0-0
Timestamp: 2025-06-30T11:52:11.055Z
Learning: Applies to {packages,plugins}/**/*.{ts,tsx} : Extract repeated components into distinct functions or components where applicable
Learnt from: CR
PR: halfdomelabs/baseplate#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T11:51:48.395Z
Learning: Applies to **/*.{ts,tsx} : Include absolute paths in import statements via tsconfig paths (`@src/` is the alias for `src/`)
Learnt from: kingston
PR: halfdomelabs/baseplate#562
File: plugins/plugin-auth/package.json:32-36
Timestamp: 2025-06-03T09:11:29.651Z
Learning: With TypeScript project references, TypeScript compilation is watched from the root level using "watch:tsc:root" script, so individual packages no longer need to include their "tsc:watch" scripts in their local "watch" commands. The local "tsc:watch" scripts are renamed from "watch:tsc" but are not meant to be run as part of the package's watch command since TypeScript watching is handled centrally at the workspace root.
Learnt from: kingston
PR: halfdomelabs/baseplate#539
File: scripts/check-changesets.ts:70-79
Timestamp: 2025-05-08T12:56:11.723Z
Learning: In the check-changesets.ts script for monorepo validation, `npm pack ${pkg.name}@latest` is intentionally used to pack the most recently published version (not local changes) for comparison purposes to determine if changes require new changesets.
Learnt from: kingston
PR: halfdomelabs/baseplate#428
File: packages/project-builder-server/src/sync/index.ts:5-5
Timestamp: 2025-01-23T09:12:46.178Z
Learning: Avoid importing directly from 'dist' directories. Instead, expose functionality through the package's public API and import from the main package entry point.
🧬 Code Graph Analysis (7)
packages/project-builder-cli/src/index.ts (1)
packages/project-builder-cli/src/commands/diff.ts (1)
addDiffCommand(13-51)
packages/project-builder-server/src/sync/build-project.ts (1)
packages/project-builder-server/src/sync/template-metadata-utils.ts (1)
createTemplateMetadataOptions(10-33)
packages/project-builder-cli/src/commands/diff.ts (4)
packages/project-builder-cli/src/utils/path.ts (1)
expandPathWithTilde(4-9)packages/project-builder-cli/src/services/schema-parser-context.ts (1)
createSchemaParserContext(12-21)packages/project-builder-cli/src/services/user-config.ts (1)
getUserConfig(22-31)packages/project-builder-server/src/diff/diff-project.ts (1)
diffProject(125-212)
packages/project-builder-server/src/sync/template-metadata-utils.ts (2)
packages/project-builder-lib/src/schema/project-definition.ts (1)
ProjectDefinition(52-54)packages/sync/src/output/generator-task-output.ts (1)
TemplateMetadataOptions(113-142)
packages/sync/src/output/prepare-generator-files/prepare-generator-file.ts (3)
packages/sync/src/output/generator-task-output.ts (1)
FileData(57-70)packages/sync/src/output/formatter.ts (1)
GeneratorOutputFormatter(20-37)packages/sync/src/utils/evented-logger.ts (1)
Logger(3-8)
packages/sync/src/output/format-generator-output.unit.test.ts (5)
packages/sync/src/utils/evented-logger.ts (1)
Logger(3-8)packages/sync/src/output/formatter.ts (1)
GeneratorOutputFormatter(20-37)packages/sync/src/output/generator-task-output.ts (1)
GeneratorTaskOutput(75-88)packages/sync/src/output/prepare-generator-files/prepare-generator-file.ts (1)
formatOutputFileContents(62-107)packages/sync/src/output/format-generator-output.ts (1)
formatGeneratorOutput(53-87)
packages/project-builder-server/src/diff/formatters.ts (1)
packages/project-builder-server/src/diff/types.ts (2)
DiffSummary(10-16)FileDiff(1-8)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Lint
- GitHub Check: Test E2E
- GitHub Check: test
🔇 Additional comments (35)
packages/project-builder-server/src/sync/build-project.ts (2)
32-32: Good refactoring - clean extraction of utility logic.The import follows the proper TypeScript conventions with
.jsextension and the utility function extraction improves code organization.
218-219: Excellent refactoring - improves maintainability.Replacing the inline template metadata options construction with the utility function call makes the code more readable and maintainable. The functionality remains the same while centralizing the logic.
packages/project-builder-cli/src/index.ts (1)
5-5: LGTM! Command integration follows established pattern.The diff command import and registration correctly follows the existing pattern used by other CLI commands in this file.
Also applies to: 26-26
packages/sync/src/output/index.ts (1)
4-4: LGTM! Export addition follows the established pattern.The barrel export for
format-generator-output.jsis correctly placed and follows the existing pattern in this index file.packages/project-builder-server/src/diff/index.ts (1)
1-4: LGTM! Well-structured barrel export for diff functionality.The new diff index file correctly implements the established pattern for barrel exports, properly using
export type *for the types module and regular exports for implementation modules.packages/project-builder-server/src/index.ts (1)
3-3: LGTM! Export addition maintains proper organization.The diff module export is correctly placed in alphabetical order and follows the established pattern for main package exports.
packages/project-builder-server/package.json (1)
63-63: Dependency versions are up-to-date; please complete a security auditAll newly added packages are pinned to the latest published versions:
- [email protected]
- [email protected]
- [email protected]
- @types/[email protected]
- @types/[email protected]
Next steps:
- In packages/project-builder-server, run
npm install --package-lock-onlyto generate a lockfile.- Run
npm auditand address any reported vulnerabilities before merging.package.json (1)
34-34: LGTM! Script naming follows conventions.The change from "serve" to "start" follows Node.js conventions and the switch to pnpm filtering provides more direct control over the CLI execution.
packages/sync/src/output/format-generator-output.unit.test.ts (5)
1-18: LGTM! Test setup follows best practices.The test file correctly uses vitest with explicit imports, proper mocking patterns, and dynamic imports for the mocked module. The mock setup is clean and follows the project's testing conventions.
19-47: Well-structured test setup with proper mocks.The test setup includes proper mock objects for Logger and GeneratorOutputFormatter with appropriate TypeScript typing. The beforeEach hook correctly clears mocks and resets expectations.
49-107: Comprehensive test coverage for main functionality.The test follows the Arrange-Act-Assert pattern clearly and verifies that
formatOutputFileContentsis called with the correct parameters for each file. The assertions properly check both the function calls and the result structure.
109-140: Good test for file options preservation.This test ensures that file options are preserved during the formatting process, which is important for maintaining metadata like
skipFormattingflags.
142-164: Proper edge case handling.The test correctly handles the empty files scenario and verifies that no formatting calls are made when there are no files to process.
packages/project-builder-cli/src/commands/diff.ts (3)
9-13: LGTM! Function signature follows TypeScript guidelines.The function has explicit return type annotation and proper JSDoc documentation following the project's TypeScript coding guidelines.
14-21: Well-structured command definition.The command setup is clean with a clear description and well-defined options. The option names are intuitive and consistent with CLI conventions.
22-51: Proper async handling and configuration loading.The action handler correctly:
- Uses dynamic imports to avoid loading server code unnecessarily
- Handles path expansion with tilde support
- Loads configuration and context asynchronously
- Passes all required parameters to the diffProject function
- Uses nullish coalescing for the compact option default
packages/project-builder-server/src/diff/types.ts (3)
1-8: Well-defined FileDiff interface.The interface properly handles all aspects of file differences including:
- Path and change type information
- Optional content for both generated and working versions
- Binary file flag for proper handling
- Optional unified diff string for formatting
- Supports both string and Buffer content types
10-16: Comprehensive DiffSummary interface.The interface provides good aggregation of diff information with separate counts for each type of change and an array of individual file diffs.
18-22: Appropriate DiffOptions interface.The options interface covers the expected configuration parameters for diff operations with proper optional typing.
.changeset/add-diff-command.md (1)
1-18: Well-documented changeset for the new diff command.The changeset properly documents the new feature with:
- Correct package references and patch version bumps
- Clear description of the command's purpose
- Comprehensive list of features and capabilities
- Good explanation of the business value
packages/project-builder-server/src/diff/diff-utils.unit.test.ts (1)
1-216: Excellent test coverage and structure!The test file follows all coding guidelines perfectly:
- Explicit vitest imports as required
- Proper use of memfs for file system operations
- Comprehensive coverage of all utility functions
- Clear test structure with descriptive names
- Good edge case coverage including binary files, glob patterns, and error conditions
The tests provide solid foundation for the new diff functionality.
packages/sync/src/output/prepare-generator-files/prepare-generator-file.ts (3)
62-74: Well-executed refactoring for better modularity!The function signature change from a single context object to destructured parameters makes the dependencies explicit and improves reusability. The export enables the diff functionality to leverage this formatting logic.
210-214: Consistent usage of refactored function.The call to
formatOutputFileContentscorrectly uses the new parameter structure, maintaining consistency with the refactored signature.
333-337: Proper function call with new signature.The
formatOutputFileContentscall correctly passes the context object, aligning with the refactored function signature.packages/project-builder-server/src/diff/formatters.ts (3)
8-64: Well-structured compact diff formatter!The function provides clear, color-coded output with proper grouping by file type. The handling of binary files and the summary header makes the output very readable.
69-99: Effective file diff formatting with good color coding.The unified diff colorization is intuitive and follows standard conventions. The binary file handling is appropriate.
104-127: Clean unified diff formatter implementation.The function provides a comprehensive view of all changes with proper spacing and formatting. Good use of the
formatFileDifffunction for consistency.packages/project-builder-server/src/diff/diff-utils.ts (5)
14-22: Simple and effective file filtering logic.The function correctly handles the case where no patterns are provided and uses micromatch for pattern matching.
27-42: Robust file reading with proper error handling.The function correctly handles binary detection and file not found errors. The error handling for ENOENT is appropriate.
47-49: Clear binary content detection.Simple and effective implementation for determining if generated content is binary.
54-67: Standard unified diff generation.Uses the diff library appropriately with clear file labels for working vs generated content.
72-157: Comprehensive file comparison logic with good structure.The function handles all major scenarios: added files, modified files, binary files, and text files. The logic is well-organized and the TODO comment honestly acknowledges the missing deleted file detection.
packages/sync/src/output/format-generator-output.ts (2)
14-44: Well-defined interfaces for formatting operations.The interfaces clearly specify the required parameters and return values, making the API easy to understand and use.
53-87: Clean implementation of generator output formatting.The function properly leverages the refactored
formatOutputFileContentsfunction, preserves file metadata, and provides a sensible default for the logger. The async processing of all files is handled correctly.packages/project-builder-server/src/diff/formatters.unit.test.ts (1)
1-196: Well-structured test suite!The test file follows all best practices:
- Explicit vitest imports
- Descriptive test names
- Clear AAA pattern
- Comprehensive coverage including edge cases
- Tests verify specific behaviors
packages/project-builder-server/src/sync/template-metadata-utils.ts
Outdated
Show resolved
Hide resolved
| if (!projectJson.settings.templateExtractor?.writeMetadata) { | ||
| return undefined; | ||
| } | ||
|
|
||
| const fileIdRegexWhitelist = | ||
| projectJson.settings.templateExtractor.fileIdRegexWhitelist.split('\n'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add null safety check for fileIdRegexWhitelist.
The code assumes fileIdRegexWhitelist exists when writeMetadata is enabled, but this might not be guaranteed by the schema. Consider adding a null check or providing a default value.
+ const fileIdRegexWhitelist = projectJson.settings.templateExtractor.fileIdRegexWhitelist ?? '';
- const fileIdRegexWhitelist =
- projectJson.settings.templateExtractor.fileIdRegexWhitelist.split('\n');
+ const patterns = fileIdRegexWhitelist.split('\n');📝 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.
| if (!projectJson.settings.templateExtractor?.writeMetadata) { | |
| return undefined; | |
| } | |
| const fileIdRegexWhitelist = | |
| projectJson.settings.templateExtractor.fileIdRegexWhitelist.split('\n'); | |
| if (!projectJson.settings.templateExtractor?.writeMetadata) { | |
| return undefined; | |
| } | |
| const fileIdRegexWhitelist = projectJson.settings.templateExtractor.fileIdRegexWhitelist ?? ''; | |
| const patterns = fileIdRegexWhitelist.split('\n'); |
🤖 Prompt for AI Agents
In packages/project-builder-server/src/sync/template-metadata-utils.ts around
lines 13 to 18, the code assumes
projectJson.settings.templateExtractor.fileIdRegexWhitelist is always defined
when writeMetadata is enabled, which may not be true. Add a null safety check
for fileIdRegexWhitelist before splitting it by '\n', or provide a default empty
string or array to avoid runtime errors if it is undefined or null.
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Tests
Chores