Skip to content

fix(create): align built-in library toolchain versions - #2721

Open
SaKaNa-Y wants to merge 3 commits into
voidzero-dev:mainfrom
SaKaNa-Y:fix/create-library-version
Open

SaKaNa-Y wants to merge 3 commits into
voidzero-dev:mainfrom
SaKaNa-Y:fix/create-library-version

Conversation

@SaKaNa-Y

@SaKaNa-Y SaKaNa-Y commented Sep 16, 2026 •

Copy link
Copy Markdown
Contributor

Important

Please take a moment to read this. Thank you!

I should include a brief explanation of the problem in my own words in every PR. If that explanation is missing, please @mention me and do not merge this PR until I have added it. You may also leave this PR unaddressed (because this means I have not fulfilled my responsibilities as the author).

If my explanation is unclear or difficult to follow, please ask me to clarify or provide reproduction steps or supporting evidence.

I welcome suggestions and counterarguments, especially questions about anything I may have overlooked. (Your feedback helps me learn and improve. 🙏)

I hold myself to this standard for every PR, regardless of its size.

Problem

Creating a standalone library with Vite+ 1.0.0 and npm or Bun installs vite-plus@0.2.9 alongside @voidzero-dev/vite-plus-core@1.0.0. The remote library template declares vite-plus: ^0.2.4, and creation preserves that range while writing the creating CLI's core override. npm monorepos also retain the stale range in their generated packages/utils or a newly added library. These packages need consistent toolchain versions. The reproduced standalone npm library still passes checks, tests and packaging, so version inconsistency is the confirmed defect.

Fix

Set the name and Vite+ dependency of each downloaded built-in library before project integration. A shared step covers standalone libraries, libraries added to existing workspaces, and the library created by vite:monorepo. Catalog-based integration can still replace the version with a catalog reference.

Run the built-in create CI matrix without forced migration, which previously masked the stale dependency. Assert the installed Vite+ and resolved core versions from each generated package. The four package-manager jobs also add a library to an installed workspace, compare the root configuration before and after, and run the new library's tests.

Verification

  • This review: all four package managers passed workspace creation, member installation, version assertions and member tests. The existing root configuration stayed unchanged. The new CI shell step also passed locally for all four, using the local 1.0.0 artifacts.
  • This review: the added-member assertion rejects the unpatched npm path. Full unit suite: 2,203 passed, 1 skipped. Repository vp check passed formatting, lint and type checks.
  • Previous update: all 12 combinations of library, application and monorepo templates with npm, pnpm, Yarn and Bun passed installation and version assertions. Application builds and library packaging and tests also passed. Installed CLI bundles matched the local build.
  • Previous update: the npm monorepo regression failed before its fix and passed afterward. The installation assertion also rejected the unpatched npm monorepo and Bun standalone library.

Adding a library to an existing workspace still fails vp check and vp pack because the remote template uses legacy dts.tsgo: true configuration. This review reproduced the same configuration and failures with the unpatched CLI. That separate defect is covered by #2862.

Local checks used npm 12.2.0, pnpm 12.8.1, Yarn 4.18.1 and Bun 1.4.2 on macOS. The CLI JavaScript was rebuilt with existing native and core artifacts. The full CLI snapshot suite was not rerun. Hosted CI results are pending.

@SaKaNa-Y SaKaNa-Y changed the title fix(create): align new library dependencies with the CLI version fix(create): pin new libraries to the creating CLI version Sep 16, 2026
The remote library template can retain an older vite-plus range while project setup injects the current core override. Pin the newly scaffolded library to the creating CLI before integration, without changing migration rules for existing projects.
@SaKaNa-Y
SaKaNa-Y force-pushed the fix/create-library-version branch from 8baae99 to a5c0340 Compare October 2, 2026 14:47
Prepare both built-in library download paths with the creating CLI version before project integration. Keep existing migration rules and workspace configuration cleanup.

Run built-in create CI cases without forced migration and assert the installed CLI and resolved core in each generated package. Cover npm monorepos and catalog-based package managers with regression tests.
Exercise library creation inside an installed workspace for all four package managers. Check member and root toolchain resolution, preserve root configuration, and run member tests.
@SaKaNa-Y SaKaNa-Y changed the title fix(create): pin new libraries to the creating CLI version fix(create): align built-in library toolchain versions Oct 3, 2026
@SaKaNa-Y
SaKaNa-Y marked this pull request as ready for review October 3, 2026 07:12
@SaKaNa-Y

SaKaNa-Y commented Oct 3, 2026

Copy link
Copy Markdown
Contributor Author

When creating a library with Vite+ 1.0.0 and npm, the generated package.json still declares "vite-plus": "^0.2.4". The old range comes from the remote library template. The creation process preserves it while setting the core override to 1.0.0. This leaves the project with inconsistent toolchain versions.

The same problem affects standalone libraries created with Bun and libraries created inside npm workspaces. This includes packages/utils from the monorepo template and libraries added to existing workspaces.

@fengmk2

fengmk2 commented Oct 3, 2026

Copy link
Copy Markdown
Member

Could you submit a PR to https://github.com/sxzz/tsdown-templates/blob/main/vite-plus to update the content?

@SaKaNa-Y

SaKaNa-Y commented Oct 4, 2026

Copy link
Copy Markdown
Contributor Author

Could you submit a PR to https://github.com/sxzz/tsdown-templates/blob/main/vite-plus to update the content?

This PR makes the generated library use the same Vite+ version as the CLI that creates it. It removes the need to keep the template's version declaration up to date.

Updating the template fixes the outdated version, but it does not guarantee that the version matches the CLI that the user runs. This PR sets the version after downloading the template, so the template's old version does not affect the generated project.

So do you think a separate PR to the template repository is still necessary? 🤔

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants