fix: deployment nodes name is wrong derived from instanceOf#2476
fix: deployment nodes name is wrong derived from instanceOf#2476
Conversation
🦋 Changeset detectedLatest commit: 4f808ec The changes in this PR will be included in the next version bump. 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 💥 An error occurred when fetching the changed packages and changesets in this PR |
📝 WalkthroughWalkthroughRefactors deployment-node construction and relationship-merge logic, adds single-instance inheritance, removes a Builder runtime invariant, exposes deployment element icon getter, adds tests for deployment nodes and relationship merging, and introduces CI/workflow tooling and changeset/configuration files. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 2 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
packages/language-server/src/model/__tests__/__snapshots__/model-builder.spec.ts.snapis excluded by!**/*.snap
📒 Files selected for processing (7)
.oxlintrc.json(1 hunks)packages/core/src/builder/Builder.ts(1 hunks)packages/core/src/compute-view/deployment-view/__test__/buildNodes.spec.ts(1 hunks)packages/core/src/compute-view/deployment-view/utils.ts(5 hunks)packages/core/src/compute-view/utils/merge-props-from-relationships.spec.ts(1 hunks)packages/core/src/compute-view/utils/merge-props-from-relationships.ts(4 hunks)packages/core/src/model/DeploymentElementModel.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use
pnpm ci:typecheckfor TypeScript type checking across all packages except documentation
Files:
packages/core/src/model/DeploymentElementModel.tspackages/core/src/compute-view/deployment-view/__test__/buildNodes.spec.tspackages/core/src/compute-view/utils/merge-props-from-relationships.spec.tspackages/core/src/compute-view/deployment-view/utils.tspackages/core/src/compute-view/utils/merge-props-from-relationships.tspackages/core/src/builder/Builder.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use oxlint with type-aware rules for linting instead of eslint, and run
pnpm ci:lintto validate all packages except documentation
Files:
packages/core/src/model/DeploymentElementModel.tspackages/core/src/compute-view/deployment-view/__test__/buildNodes.spec.tspackages/core/src/compute-view/utils/merge-props-from-relationships.spec.tspackages/core/src/compute-view/deployment-view/utils.tspackages/core/src/compute-view/utils/merge-props-from-relationships.tspackages/core/src/builder/Builder.ts
**/*.{ts,tsx,js,jsx,json,md}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use
pnpm fmtto format code with dprint instead of Prettier or eslint for formatting
Files:
packages/core/src/model/DeploymentElementModel.tspackages/core/src/compute-view/deployment-view/__test__/buildNodes.spec.tspackages/core/src/compute-view/utils/merge-props-from-relationships.spec.tspackages/core/src/compute-view/deployment-view/utils.tspackages/core/src/compute-view/utils/merge-props-from-relationships.tspackages/core/src/builder/Builder.ts
packages/*/**/!(node_modules)/**/*.spec.ts
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Unit tests must be located in
packages/*/src/**/*.spec.tsorpackages/*/src/**/__test__/*.spec.tsfiles
Files:
packages/core/src/compute-view/deployment-view/__test__/buildNodes.spec.tspackages/core/src/compute-view/utils/merge-props-from-relationships.spec.ts
🧠 Learnings (4)
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to packages/*/**/!(node_modules)/**/*.spec.ts : Unit tests must be located in `packages/*/src/**/*.spec.ts` or `packages/*/src/**/__test__/*.spec.ts` files
Applied to files:
packages/core/src/compute-view/deployment-view/__test__/buildNodes.spec.tspackages/core/src/compute-view/utils/merge-props-from-relationships.spec.ts
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use oxlint with type-aware rules for linting instead of eslint, and run `pnpm ci:lint` to validate all packages except documentation
Applied to files:
.oxlintrc.json
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to **/*.{ts,tsx} : Use `pnpm ci:typecheck` for TypeScript type checking across all packages except documentation
Applied to files:
.oxlintrc.json
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to **/*.{ts,tsx,js,jsx,json,md} : Use `pnpm fmt` to format code with dprint instead of Prettier or eslint for formatting
Applied to files:
.oxlintrc.json
🧬 Code graph analysis (5)
packages/core/src/model/DeploymentElementModel.ts (1)
packages/core/src/types/scalar.ts (1)
IconUrl(58-58)
packages/core/src/compute-view/deployment-view/__test__/buildNodes.spec.ts (1)
packages/core/src/builder/Builder.ts (2)
Builder(71-199)Builder(894-971)
packages/core/src/compute-view/utils/merge-props-from-relationships.spec.ts (4)
packages/core/src/builder/Builder.ts (1)
Any(974-974)packages/core/src/types/scalar.ts (1)
MarkdownOrString(10-10)packages/core/src/types/model-deployment.ts (1)
DeploymentRelationship(62-65)packages/core/src/compute-view/utils/merge-props-from-relationships.ts (1)
mergePropsFromRelationships(59-144)
packages/core/src/compute-view/deployment-view/utils.ts (4)
packages/core/src/model/DeploymentElementModel.ts (6)
id(506-508)id(572-574)DeployedInstanceModel(386-497)style(55-67)style(412-425)style(514-520)packages/core/src/compute-view/utils/buildComputedNodes.ts (2)
ComputedNodeSource(32-36)buildComputedNodes(59-155)packages/core/src/types/_aux.ts (3)
NodeId(178-178)preferSummary(264-266)DeploymentKind(189-189)packages/core/src/types/view-computed.ts (1)
ComputedNode(29-68)
packages/core/src/compute-view/utils/merge-props-from-relationships.ts (2)
packages/core/src/types/scalar.ts (1)
RelationKind(104-104)packages/core/src/types/_aux.ts (1)
StrictViewId(243-243)
⏰ 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). (4)
- GitHub Check: checks / 📖 docs
- GitHub Check: checks / 🔬 e2e tests
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: checks / ⊞ windows build
🔇 Additional comments (13)
packages/core/src/builder/Builder.ts (1)
867-868: LGTM! Efficient refactoring.The
withmethod now clones once upfront and applies all operations to that single clone, eliminating the redundant final clone. This improves performance without changing behavior.packages/core/src/model/DeploymentElementModel.ts (1)
81-83: LGTM! Consistent public API addition.The new
icongetter follows the existing pattern forshapeandcoloraccessors and provides convenient access to the icon URL from the element's style.packages/core/src/compute-view/utils/merge-props-from-relationships.ts (2)
16-39: LGTM! Cleaner property extraction.The refactoring to use
pickfrom remeda simplifies the code and makes optional fields more explicit. The logic correctly preserves the relationship between title and description.
114-142: LGTM! Enhanced merging with technology fallback.The refactored merging logic correctly:
- Uses undefined for absent values (more idiomatic for optional fields)
- Applies preferred properties via
pickBywithisTruthyfilter- Adds title-from-technology derivation when title is absent
The behavior is well-tested in the accompanying spec file.
packages/core/src/compute-view/utils/merge-props-from-relationships.spec.ts (1)
1-392: LGTM! Comprehensive test coverage.This test suite provides excellent coverage of the refactored
mergePropsFromRelationshipsfunction, including:
- Empty inputs and single/multiple relationship merging
- Title handling with multiple values and technology fallback
- Tag deduplication and collection
- Preferred relationship override logic
- Description deep equality checks
- Mixed relationship types (regular and deployment)
- Complex multi-way merge scenarios
The helper functions ensure type safety and the tests validate all edge cases.
packages/core/src/compute-view/deployment-view/utils.ts (5)
1-1: LGTM! Import cleanup.The import changes correctly replace
uniquewithisEmpty(for empty checks) and addWritable(for mutable node typing), while removing the unusednameFromFqnimport.Also applies to: 26-26
145-167: LGTM! Well-structured deployment node conversion.The new
deploymentNodeToNodeSourcefunction cleanly handles deployment node conversion with proper:
- Optional field handling with
?? undefinedonlyOneInstancedetection for settingmodelRef- Link array checks with
hasAtLeast- Description extraction via
preferSummary
169-198: LGTM! Instance conversion with link merging.The new
instanceToNodeSourcefunction correctly:
- Merges links from both the element and instance (lines 177-180)
- Uses
instanceSummaryhelper for description fallback- Sets both
deploymentRefandmodelRefappropriately- Preserves instance notation
200-207: LGTM! Clean internal dispatcher.The
toNodeSourcefunction now serves as an internal dispatcher, using the type guard to route to the appropriate specialized function. Making this internal (non-exported) is appropriate given the new specialized public helpers.
273-328: LGTM! Core fix for issue #2387.The new inheritance logic for single-instance deployment nodes correctly implements the expected behavior:
- Title inheritance (lines 296-298): Inherits from instance when the node title equals the deployment name (i.e., wasn't explicitly overridden)
- Property inheritance (lines 300-308): Inherits description, technology, tags, and links when not set on the node
- Style inheritance (lines 310-324): Applies instance shape/color/icon when node uses defaults, resetting notation to avoid inconsistencies
This addresses the playground example from issue #2387 where deployment nodes displayed incorrect titles. The logic is well-tested in the accompanying spec file.
packages/core/src/compute-view/deployment-view/__test__/buildNodes.spec.ts (3)
16-126: LGTM! Thorough title precedence validation.The title handling tests comprehensively validate the precedence rules:
- Spec-defined titles are preserved
- Explicitly set node titles take precedence
- Titles inherit from the model element when not in deployment
- Instance title overrides are inherited when the node title wasn't explicitly set
These tests directly validate the fix for issue #2387.
128-310: LGTM! Complete description/summary precedence coverage.The description/summary tests validate all inheritance and precedence scenarios:
- Spec descriptions are preserved
- Node descriptions/summaries override instance values
- Summary takes precedence over description on the same node
- Instance summaries inherit when node descriptions are absent
- Logical model summaries are used when not in deployment
These tests ensure the
preferSummarylogic and inheritance work correctly.
312-368: LGTM! Effective regression test for issue #2387.This test directly validates the Kubernetes namespace scenario from issue #2387:
cert_manager: Explicit title "cert-manager" is preservedkeycloak1: Title equals name and node is leaf → inherits "Identity Provider" from instancekeycloak2: Title equals name but expanded (has children) → keeps "keycloak2"keycloak3: Explicit title "Keycloak" is preservedThe test ensures the fix correctly handles the reported issue while respecting explicit titles and expanded nodes.
| "promise/no-new-statics": "error", | ||
| "react/exhaustive-deps": "warn", | ||
| "no-unused-expressions": "off", | ||
| "typescript/no-base-to-string": "off", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# 1. Check .oxlintrc.json structure and content around line 42
echo "=== .oxlintrc.json content (lines 35-55) ==="
sed -n '35,55p' .oxlintrc.json
echo -e "\n=== Checking for overrides section in .oxlintrc.json ==="
grep -n "overrides" .oxlintrc.json | head -5
echo -e "\n=== Files with inline disable for typescript/no-base-to-string ==="
rg -n "oxlint-disable.*typescript/no-base-to-string" --type ts
echo -e "\n=== Total lines in .oxlintrc.json ==="
wc -l .oxlintrc.jsonRepository: likec4/likec4
Length of output: 1133
🏁 Script executed:
#!/bin/bash
echo "=== Searching for .toString() calls that might trigger the rule ==="
rg -n "\.toString\(\)" --type ts | head -30
echo -e "\n=== Checking if there are many files with violations ==="
rg "\.toString\(\)" --type ts -c | wc -l
echo -e "\n=== Show files with .toString() calls ==="
rg -l "\.toString\(\)" --type ts | head -20
echo -e "\n=== Full .oxlintrc.json to understand context ==="
cat .oxlintrc.jsonRepository: likec4/likec4
Length of output: 6208
Consider using file-specific configuration instead of a global disable for this type-aware rule.
The typescript/no-base-to-string rule is disabled project-wide via line 43. Since Oxlint supports file-specific overrides using the overrides property, you could instead:
- Extend the
overridessection (already present) to disable this rule only for specific files that need the exception (e.g., Builder.ts, which already has an inline disable) - Or configure the rule with
ignoredTypeNamesto exclude types likeURLandURIthat have legitimatetoString()methods, rather than disabling globally
This approach prevents inadvertently masking issues in files where string coercion without proper toString() methods could cause problems.
🤖 Prompt for AI Agents
.oxlintrc.json around line 42: the project currently disables
"typescript/no-base-to-string" globally which can hide legitimate type-safety
issues; update the config to either (A) move the disable into the existing
"overrides" array and target only the specific files that need it (e.g.,
Builder.ts and any others using an inline disable) so other files keep the rule
enabled, or (B) re-enable the rule globally and add an "ignoredTypeNames" entry
for known safe types like "URL" and "URI" so their toString() usages are allowed
while preserving the rule for all other types; pick one approach and adjust the
.oxlintrc.json accordingly.
- Updated pnpm-workspace.yaml to include new dependencies and adjust package exclusions. - Added README.md for changesets documentation. - Created config.json for changesets configuration. - Added a changeset for patch updates to @likec4/core and @likec4/language-server. - Introduced a GitHub Action for creating a bot token with configurable options.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/copilot-instructions.md (1)
129-136: Clarify CI command naming convention.There's an apparent inconsistency: earlier sections recommend
pnpm typecheckandpnpm lint(lines 28, 38) for local development, but the CI workflow section referencespnpm ci:typecheckandpnpm ci:lint. If CI uses a different set of commands with theci:prefix, this should be explicitly clarified to avoid confusion..github/actions/bot-token/action.yml (1)
43-49: Consider error handling for private key decoding.The stderr redirection (
&> /dev/null) suppresses any errors during base64 decoding. If the private key is malformed or the decoding fails, the workflow will continue with an empty or invalid key, potentially causing cryptic failures in subsequent steps.Consider handling decode errors explicitly or at minimum removing the stderr suppression to make debugging easier.
🔎 Suggested improvement:
- private_key=$(echo "${{ inputs.private-key-base64 }}" | base64 -d | awk 'BEGIN {ORS="\\n"} {print}' | head -c -2) &> /dev/null + private_key=$(echo "${{ inputs.private-key-base64 }}" | base64 -d | awk 'BEGIN {ORS="\\n"} {print}' | head -c -2) + if [ -z "$private_key" ]; then + echo "::error::Failed to decode private key" + exit 1 + fi
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (13)
.changeset/README.md(1 hunks).changeset/config.json(1 hunks).changeset/dark-turtles-stare.md(1 hunks).github/actions/bot-token/action.yml(1 hunks).github/copilot-instructions.md(9 hunks).github/workflows/e2e-update-screenshots.yaml(2 hunks).github/workflows/issue-comment.yaml(1 hunks).github/workflows/main.yml(1 hunks).github/workflows/release.yaml(2 hunks).github/workflows/trigger-deploy-template.yaml(1 hunks)devops/package.json(1 hunks)package.json(2 hunks)pnpm-workspace.yaml(6 hunks)
✅ Files skipped from review due to trivial changes (1)
- .changeset/README.md
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx,js,jsx,json,md}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use
pnpm fmtto format code with dprint instead of Prettier or eslint for formatting
Files:
devops/package.jsonpackage.json
🧠 Learnings (16)
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to packages/*/package.json : When adding new dependencies to any package, check if a catalog version exists in `pnpm-workspace.yaml` and use catalog versions when available for consistency
Applied to files:
package.json.github/copilot-instructions.mdpnpm-workspace.yaml
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Ensure Node.js version matches ^20.19.0 or >=22.18.0, and pnpm version is 10.19.0 as specified in .tool-versions
Applied to files:
package.json.github/copilot-instructions.mdpnpm-workspace.yaml
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to packages/vscode/**/*.{ts,tsx} : For VSCode extension development, use `pnpm dev` in `packages/vscode` to watch for changes in dependencies and launch with F5 in VSCode
Applied to files:
package.json.github/copilot-instructions.mdpnpm-workspace.yaml
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to {packages/language-server/src/generated/**/*,packages/vscode/src/meta.ts,packages/likec4/app/src/routeTree.gen.ts,styled-system/preset/src/generated.ts} : Generated files in `packages/language-server/src/generated/`, `packages/vscode/src/meta.ts`, `packages/likec4/app/src/routeTree.gen.ts`, and `styled-system/preset/src/generated.ts` must be regenerated via `pnpm generate` and should not be manually edited
Applied to files:
package.json.github/copilot-instructions.mdpnpm-workspace.yaml
📚 Learning: 2025-12-05T15:36:11.989Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.989Z
Learning: Always run `pnpm generate` first before building or after cleaning to regenerate TypeScript types, Langium parser, and other code-generated files
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Run `pnpm clean` when encountering TypeScript project reference errors or stale cache issues, followed by `pnpm generate && pnpm typecheck`
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to **/*.{ts,tsx} : Use `pnpm ci:typecheck` for TypeScript type checking across all packages except documentation
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to apps/playground/**/*.{ts,tsx} : For playground development, use `pnpm dev` in `apps/playground` for dev server with hot reload
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use oxlint with type-aware rules for linting instead of eslint, and run `pnpm ci:lint` to validate all packages except documentation
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Set `HUSKY=0` and `NODE_ENV=development` environment variables when running `pnpm install` to prevent husky pre-commit hook setup issues
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to **/*.{ts,tsx,js,jsx,json,md} : Use `pnpm fmt` to format code with dprint instead of Prettier or eslint for formatting
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Use `NODE_ENV=development` for development work and install commands, and `NODE_ENV=production` or `NODE_ENV=test` for CI commands
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to packages/*/**/!(node_modules)/**/*.spec.ts : Unit tests must be located in `packages/*/src/**/*.spec.ts` or `packages/*/src/**/__test__/*.spec.ts` files
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Do not commit build artifacts including `lib/`, `dist/`, `.turbo/`, generated files, and other gitignored outputs
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Applies to e2e/{tests,src}/**/*.spec.ts : E2E tests must be located in `e2e/tests/*.spec.ts` or `e2e/src/*.spec.ts` files
Applied to files:
.github/copilot-instructions.md
📚 Learning: 2025-12-05T15:36:11.990Z
Learnt from: CR
Repo: likec4/likec4 PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-05T15:36:11.990Z
Learning: Use TypeScript with TypeScript project references for faster incremental builds across packages in the monorepo
Applied to files:
.github/copilot-instructions.md
🪛 LanguageTool
.github/copilot-instructions.md
[uncategorized] ~138-~138: The official name of this software platform is spelled with a capital “H”.
Context: ...cumentation site Bootstrap Action (.github/actions/bootstrap/action.yml): ```yam...
(GITHUB)
⏰ 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). (5)
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: checks / 🛠️ build
- GitHub Check: checks / ʦ typescript
- GitHub Check: checks / ⊞ windows build
- GitHub Check: checks / 🔬 tests
🔇 Additional comments (20)
.changeset/dark-turtles-stare.md (1)
1-6: Changeset looks good!The changeset correctly declares patch-level bumps for "@likec4/core" and "@likec4/language-server", which is appropriate for this bug fix. The description is clear and properly references the issue being fixed.
devops/package.json (1)
5-5: LGTM!Adding
"private": trueis appropriate for internal tooling packages to prevent accidental publication to the npm registry..changeset/config.json (1)
1-29: LGTM!The changeset configuration is well-structured with appropriate settings for a monorepo. The fixed versioning group ensures all @likec4/* packages are released together, which maintains version consistency across the ecosystem.
package.json (2)
10-11: LGTM!Adding the
styled-system/*workspace is appropriate for including new packages in that directory.
44-44: LGTM!Correctly uses the catalog reference for
@changesets/cli, which promotes version consistency across the workspace.pnpm-workspace.yaml (3)
6-6: LGTM!Excluding
packages/create-likec4from the workspace is consistent with the changeset configuration and appropriate for independently versioned packages.
9-9: LGTM!Adding
@changesets/clito the catalog ensures consistent versioning across the workspace and aligns with the project's practice of using catalog references for shared dependencies.
87-88: LGTM!Explicitly defining React versions in the catalog improves dependency management clarity and ensures consistent React versions across all packages.
.github/workflows/issue-comment.yaml (2)
31-52: LGTM! Permission check migrated to github-script.The migration from a third-party action to github-script for permission checking is well-implemented. The logic correctly fetches the collaborator's permission level and outputs both the raw permission and a boolean-like allowed flag for downstream use.
54-61: LGTM! PR refs resolution migrated to github-script.The migration from a third-party action to github-script for resolving PR refs is straightforward and correct. The implementation derives the PR ref from the issue number and exports it appropriately.
.github/workflows/main.yml (2)
35-35: Verify release workflow triggering behavior.The release job condition was simplified to only check
repository_owner == 'likec4', removing the previous requirement for'chore: release'in the commit message. Combined with the switch tochangesets/action@v1(which creates release PRs), this means the release job now runs on every push to main.Please confirm this is intentional and that the changesets action handles release detection appropriately without causing unwanted workflow runs.
42-50: Verify intentional disabling of VSCode workflow.The VSCode workflow is commented out, effectively disabling VSCode extension publishing. Please confirm this is intentional and document the reason if this is a temporary measure.
.github/workflows/trigger-deploy-template.yaml (1)
14-22: LGTM! Clean migration to bot-token action.The workflow correctly migrates from the inline app-token flow to the new composite bot-token action. The input changes (private-key → private-key-base64, added fetch-user-id/configure-git flags) align with the new action's interface, and setting fetch-user-id and configure-git to "false" is appropriate for this use case.
Also applies to: 27-27
.github/workflows/e2e-update-screenshots.yaml (1)
22-27: LGTM! Migration to bot-token action is correct.The workflow properly migrates to the new bot-token action. Since fetch-user-id and configure-git default to "true", the action will configure git identity, which is appropriate for this workflow that creates commits and pull requests.
Also applies to: 29-32, 58-58
.github/actions/bot-token/action.yml (3)
51-64: LGTM! Conditional token creation is correct.The conditional approach to handle optional owner input is appropriate. Since the GitHub App token action requires the owner parameter to be omitted (not just empty) when not needed, using two separate conditional steps is the correct solution.
66-71: LGTM! Output collection using fallback pattern.The use of
||to select between conditional step outputs is a standard pattern and works correctly since exactly one of the two token creation steps will execute.
81-96: LGTM! Bot identity and git configuration are correct.The bot identity construction follows GitHub's conventions for bot accounts. The git configuration uses
--global, which is appropriate for GitHub Actions since each job runs in an isolated environment..github/workflows/release.yaml (2)
31-40: LGTM! Bot-token migration is correct.The workflow correctly migrates to the bot-token action. The defaults (fetch-user-id and configure-git both true) are appropriate since the release workflow needs to create commits and tags.
50-61: Updatepackage.jsonrelease script and add changesets configuration for future publishing.Changesets is properly configured with
.changeset/config.jsonand@changesets/cliinstalled. However, thepackage.jsonstill references the old ShipJS command ("release": "shipjs prepare"). Replace it with a changesets-based release script or remove it entirely if planning to add apublishstep to the workflow later. When ready to automate publishing, add aci:publishscript (e.g.,"ci:publish": "pnpm build && changeset publish") and update the workflow with apublishinput..github/copilot-instructions.md (1)
9-9: Documentation correctly distinguishes local development and CI commands—no issues found.The copilot-instructions.md properly uses non-prefixed commands (
pnpm build,pnpm typecheck,pnpm test) for local development workflows and ci-prefixed commands (pnpm ci:build,pnpm ci:typecheck,pnpm ci:test) for CI/CD sections. Both command forms coexist in package.json and serve different purposes. The Node.js and pnpm versions (22.21.1 and 10.26.0) match .tool-versions exactly.
| ], | ||
| "engines": { | ||
| "node": "^20.19.0 || >=22.18.0" | ||
| "node": ">=22.21.1" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Read package.json around line 14
head -20 package.json | cat -nRepository: likec4/likec4
Length of output: 629
🏁 Script executed:
#!/bin/bash
# Check .tool-versions file mentioned in learning
echo "=== .tool-versions ==="
cat .tool-versions
echo -e "\n=== CI/CD workflows with Node version references ==="
rg -n "node.*version|NODE_VERSION|uses:.*node" -g "*.{yml,yaml}" .github/workflows/ 2>/dev/null | head -30
echo -e "\n=== Node version in README ==="
rg -n "node|Node" README.md 2>/dev/null | head -20Repository: likec4/likec4
Length of output: 503
🏁 Script executed:
#!/bin/bash
# Check for other files that might document Node version requirements
echo "=== Checking for Node version documentation in various files ==="
rg -l "node.*version|minimum.*node|require.*node" -g "*.md" . 2>/dev/null | head -20
echo -e "\n=== Checking CHANGELOG or release notes ==="
ls -la CHANGELOG* RELEASE* 2>/dev/null || echo "No CHANGELOG/RELEASE files found"
echo -e "\n=== Checking package.json engines across workspaces ==="
find . -name "package.json" -path "*/apps/*/package.json" -o -path "*/packages/*/package.json" | xargs grep -l '"engines"' 2>/dev/null | head -5Repository: likec4/likec4
Length of output: 591
🏁 Script executed:
#!/bin/bash
# Check CONTRIBUTING.md for Node requirements
echo "=== CONTRIBUTING.md Node version references ==="
rg -n "node|Node|javascript" CONTRIBUTING.md 2>/dev/null | head -20
echo -e "\n=== Checking workspace package.json engines ==="
for f in ./packages/likec4/package.json ./packages/language-server/package.json ./packages/create-likec4/package.json ./packages/vscode/package.json; do
if [ -f "$f" ]; then
echo -e "\n--- $f ---"
rg -A2 '"engines"' "$f"
fi
done
echo -e "\n=== Checking recent CHANGELOG entries for Node version changes ==="
head -100 CHANGELOG.md | grep -i "node\|engine\|version" || echo "No recent Node version mentions in CHANGELOG"Repository: likec4/likec4
Length of output: 1015
Resolve the Node version engine inconsistency between root and workspace packages.
The root package.json now requires >=22.21.1, but workspace packages (likec4, language-server) still declare ^20.19.0 || >=22.18.0, creating an incompatible constraint. Either:
- Update all workspace package.json files to
>=22.21.1to match the root requirement, or - Revert the root constraint to align with workspace declarations
Also, update CONTRIBUTING.md to document the minimum Node.js version requirement since it currently only states "Project requires Node.js" without specifying a version.
🤖 Prompt for AI Agents
In package.json around line 14, the root engine requires "node": ">=22.21.1" but
workspace packages still use "^20.19.0 || >=22.18.0", causing an inconsistent
Node version policy; either update every workspace package.json engine field to
">=22.21.1" to match the root (search workspaces like c4 and language-server and
update their "engines.node" fields) or change the root package.json back to the
broader constraint used by workspaces, and then update CONTRIBUTING.md to
explicitly state the chosen minimum Node.js version (add a short line under
requirements specifying "Node.js >=22.21.1" if you choose the root requirement)
so all manifests and docs align.
1 participant
This pull request focuses on improving how deployment nodes inherit and display properties such as title, description, summary, and style, especially when there is only one instance associated with a deployment node. It also adds comprehensive tests to ensure correct property inheritance and precedence. Additionally, there are minor code quality improvements and a lint rule adjustment.
Deployment Node Property Inheritance and Precedence Improvements:
toNodeSourceand related functions inutils.tsto ensure deployment nodes with only one instance correctly inherit properties (title, description/summary, technology, tags, links, and styles) from their instance when not explicitly set, and clarified the rules for when to override or inherit these values. [1] [2] [3]Testing Enhancements:
buildNodes.spec.tsto verify property inheritance and precedence for deployment nodes, including edge cases and regression for issue Deployment nodes name is wrong derived from instanceOf #2387.Code Quality and Linting:
utils.tsfor better clarity and maintainability. [1] [2]typescript/no-base-to-stringESLint rule in.oxlintrc.jsonto allow for more flexible string conversions.Builder Utility Improvements:
withmethod in the builder utility to ensure operations are applied to a clone, preventing unintended side effects.Fixes #2387
Summary by CodeRabbit
New Features
Tests
Chores / CI / Docs
✏️ Tip: You can customize this high-level summary in your review settings.