Migrate tslib version specifiers to pnpm catalog#38849
Draft
jeremymeng wants to merge 1 commit into
Draft
Conversation
Replace explicit tslib version specifiers across all workspace package.json files with "catalog:", consolidating on the single tslib entry (^2.8.1) already defined in pnpm-workspace.yaml. Previously, packages pinned tslib to a mix of ^2.2.0, ^2.6.2, ^2.6.3, ^2.7.0, and ^2.8.1; routing them all through the catalog keeps the version aligned in one place. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
github-actions
Bot
added
AgriFood
App Configuration
github-actions
Bot
added
Event Grid
Event Hubs
Health Deidentification
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Packages impacted by this PR
All workspace packages that depend on
tslib(456package.jsonfiles acrosssdk/**,common/tools/**, andeng/containers/turborepo-remote-cache).Issues associated with this PR
N/A
Describe the problem that is addressed by this PR
tslibwas pinned independently across workspace packages at a mix of^1.10.0,^2.2.0,^2.6.2,^2.6.3,^2.7.0, and^2.8.1. Atslib: ^2.8.1entry already exists inpnpm-workspace.yamlundercatalog:, so the per-package specifiers were redundant and a source of drift whenever a new package landed with whatever version its template happened to ship.This PR routes every workspace package through the catalog by replacing the explicit specifier with
"tslib": "catalog:", so the version lives in exactly one place.What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
The catalog protocol is the pattern this repo already adopted for other shared dev dependencies (
typescript,eslint,prettier,tsx, etc.). Extending it totslibis the lowest-friction option and matches existing convention. The alternative (continuing to pin per package and policing versions via lint) was rejected because it does not prevent drift.Are there test cases added in this PR? (If not, why?)
No code changes; this is a dependency-spec refactor. Validated locally with
pnpm install --lockfile-only- the onlypnpm-lock.yamldelta isspecifier:lines changing from the previous version range to'catalog:'. No resolution drift.Three
package.jsonfiles under paths explicitly excluded from the pnpm workspace (sdk/identity/identity/integration/**,sdk/identity/identity/test/manual/**) were intentionally left alone since they are not workspace members and cannot reference the catalog.Provide a list of related PRs (if any)
N/A
Command used to generate this PR:**(Applicable only to SDK release request PRs)
N/A
Checklists