fix: fix peerDependencies flag #2956
Conversation
WalkthroughThe pull request involves widespread modifications across multiple Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
Romakita
force-pushed
the
fix-peer-dependencies
branch
from
9505ab2 to
112fdde
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.
Actionable comments posted: 3
🛑 Comments failed to post (3)
packages/perf/package.json (1)
13-13: 💡 Codebase verification
Update build script to match new export key
The old
"@tsed/source"export key is still being used in the build script. Please update the following location:
tools/typescript/index.js: Update line 227 to use"tsed-source"instead of"@tsed/source"to match the new export key format.🔗 Analysis chain
Verify the impact of export key change
The change from
"@tsed/source"to"tsed-source"looks good, but as this is a breaking change, we should verify its impact.Let's check if there are any direct imports using the old export key:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any imports using the old @tsed/source export key rg -l '"@tsed/source"' || echo "No direct references found" # Search for any TypeScript/JavaScript imports using the old format rg -l "from\s+['\"]@tsed/source['\"]" || echo "No import statements found"Length of output: 157
Script:
#!/bin/bash # Check the content of tools/typescript/index.js cat tools/typescript/index.js # Look for package.json files that might have @tsed/source as a dependency rg -l '"@tsed/source"' -g 'package.json'Length of output: 6592
packages/third-parties/normalize-path/package.json (1)
12-12: 🧹 Nitpick (assertive)
LGTM! Consider documenting this breaking change
The export key change maintains consistency across all packages. However, since this is a widespread breaking change affecting all packages, consider:
- Adding a migration guide in the changelog
- Updating the documentation to reflect the new export key
- Considering a major version bump if not already planned
packages/security/oidc-provider/package.json (1)
66-71: 🧹 Nitpick (assertive)
Consider adding version upper bounds.
While using ">=8.0.0" provides flexibility, consider adding upper bounds (e.g., ">=8.0.0 <9.0.0") to prevent potential compatibility issues with major version updates.
There was a problem hiding this comment.
Actionable comments posted: 8
🔭 Outside diff range comments (2)
packages/third-parties/normalize-path/package.json (1)
Line range hint
1-24: Consider adding migration documentation for the export key change.The systematic change from
"@tsed/source"to"tsed-source"across all packages is a significant change that could affect build tools and development workflows. Consider:
- Adding a migration guide entry
- Updating any internal tools that might be using the source field
- Communicating this change to the community, especially for packages that are commonly used by external tools
package.json (1)
Line range hint
1-1: Consider documenting these breaking changes.This PR introduces significant changes across multiple packages:
- Standardizing export keys from "@tsed/source" to "tsed-source"
- Relaxing peer dependency version constraints
Consider:
- Adding migration guides for the export key changes
- Documenting the new version policy in the README
- Adding test coverage for compatibility with different dependency versions
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (2)
packages/platform/platform-router/test/__snapshots__/routers.integration.spec.ts.snapis excluded by!**/*.snapyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (63)
lerna.json(1 hunks)package.json(1 hunks)packages/core/package.json(1 hunks)packages/di/package.json(2 hunks)packages/engines/package.json(1 hunks)packages/graphql/apollo/package.json(2 hunks)packages/graphql/graphql-ws/package.json(2 hunks)packages/graphql/typegraphql/package.json(1 hunks)packages/hooks/package.json(1 hunks)packages/orm/adapters-redis/package.json(2 hunks)packages/orm/adapters/package.json(2 hunks)packages/orm/ioredis/package.json(2 hunks)packages/orm/mikro-orm/package.json(2 hunks)packages/orm/mongoose/package.json(2 hunks)packages/orm/objection/package.json(2 hunks)packages/orm/prisma/package.json(2 hunks)packages/orm/testcontainers-mongo/package.json(2 hunks)packages/perf/package.json(1 hunks)packages/platform/common/package.json(1 hunks)packages/platform/platform-cache/package.json(2 hunks)packages/platform/platform-exceptions/package.json(2 hunks)packages/platform/platform-express/package.json(2 hunks)packages/platform/platform-http/package.json(1 hunks)packages/platform/platform-koa/package.json(2 hunks)packages/platform/platform-log-middleware/package.json(2 hunks)packages/platform/platform-log-request/package.json(2 hunks)packages/platform/platform-middlewares/package.json(2 hunks)packages/platform/platform-params/package.json(2 hunks)packages/platform/platform-response-filter/package.json(2 hunks)packages/platform/platform-router/package.json(2 hunks)packages/platform/platform-serverless-http/package.json(2 hunks)packages/platform/platform-serverless-testing/package.json(2 hunks)packages/platform/platform-serverless/package.json(2 hunks)packages/platform/platform-test-sdk/package.json(1 hunks)packages/platform/platform-views/package.json(2 hunks)packages/security/jwks/package.json(1 hunks)packages/security/oidc-provider-plugin-wildcard-redirect-uri/package.json(2 hunks)packages/security/oidc-provider/package.json(2 hunks)packages/security/passport/package.json(2 hunks)packages/specs/ajv/package.json(2 hunks)packages/specs/exceptions/package.json(2 hunks)packages/specs/json-mapper/package.json(2 hunks)packages/specs/openapi-utils/package.json(2 hunks)packages/specs/openspec/package.json(1 hunks)packages/specs/scalar/package.json(2 hunks)packages/specs/schema/package.json(2 hunks)packages/specs/swagger/package.json(2 hunks)packages/third-parties/agenda/package.json(1 hunks)packages/third-parties/bullmq/package.json(1 hunks)packages/third-parties/components-scan/package.json(2 hunks)packages/third-parties/event-emitter/package.json(1 hunks)packages/third-parties/formio-types/package.json(1 hunks)packages/third-parties/formio/package.json(2 hunks)packages/third-parties/normalize-path/package.json(1 hunks)packages/third-parties/pulse/package.json(1 hunks)packages/third-parties/schema-formio/package.json(2 hunks)packages/third-parties/socketio-testing/package.json(2 hunks)packages/third-parties/socketio/package.json(2 hunks)packages/third-parties/sse/package.json(2 hunks)packages/third-parties/stripe/package.json(2 hunks)packages/third-parties/temporal/package.json(1 hunks)packages/third-parties/terminus/package.json(2 hunks)packages/third-parties/vike/package.json(2 hunks)
🔇 Additional comments (77)
lerna.json (1)
17-17: LGTM!The formatting change to
npmClientArgsis purely cosmetic and maintains the same functionality.packages/security/jwks/package.json (1)
12-12: LGTM!The export key change is consistent with other packages and doesn't affect the security aspects of the package.
packages/third-parties/normalize-path/package.json (1)
12-12: LGTM! Verify third-party package compatibility.The export key change is consistent with other packages. Since this is a third-party integration package, ensure that the change doesn't affect any external tools or build processes that might be using the source field.
Run this script to check for any integration tests that might be affected:
✅ Verification successful
Source field change is safe to proceed ✅
The verification shows that all imports use the package name
@tsed/normalize-pathrather than direct source paths, and the change follows the consistent pattern seen across other packages. No compatibility issues were found.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for integration tests that might be using the source field rg -l "normalize-path.*source" --type ts --type js test/Length of output: 104
Script:
#!/bin/bash # Search for normalize-path package references echo "=== Package References ===" fd package.json --type f --exec rg -l "normalize-path" echo -e "\n=== Source Imports ===" rg -l "@tsed/normalize-path" --type ts --type js echo -e "\n=== Build Configs ===" fd "tsconfig|rollup|webpack" --extension json --extension config.js --extension config.ts --exec rg -l "normalize-path"Length of output: 3710
packages/third-parties/formio-types/package.json (1)
20-20: LGTM! Export key renamed consistently.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
packages/third-parties/socketio-testing/package.json (2)
12-12: LGTM! Export key renamed consistently.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
36-38: LGTM! Peer dependencies updated for better compatibility.The change from fixed version "8.4.0" to ">=8.0.0" provides more flexibility while ensuring minimum compatibility.
packages/specs/exceptions/package.json (2)
12-12: LGTM! Export key renamed consistently.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
39-39: LGTM! Peer dependency updated for better compatibility.The change from fixed version "8.4.0" to ">=8.0.0" provides more flexibility while ensuring minimum compatibility.
packages/third-parties/agenda/package.json (1)
12-12: LGTM! Export key renamed consistently.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
packages/third-parties/pulse/package.json (2)
12-12: LGTM! Export key renamed consistently.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
Line range hint
1-1: Verify consistency across the monorepo.Let's ensure all packages have been updated consistently:
✅ Verification successful
All packages are using the correct export format
The verification shows that:
- All packages with exports are consistently using "tsed-source"
- No packages have fixed version 8.4.0 in peerDependencies
- Tools packages have appropriate export formats for their specific needs
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify export key changes and peer dependencies across all package.json files echo "Checking for any remaining @tsed/source exports..." fd package.json | xargs jq -r 'select(.exports != null) | select(.exports["."]["@tsed/source"] != null) | input_filename' echo "Checking for any fixed version 8.4.0 in peerDependencies..." fd package.json | xargs jq -r 'select(.peerDependencies != null) | select(.peerDependencies["@tsed/core"] == "8.4.0" or .peerDependencies["@tsed/di"] == "8.4.0" or .peerDependencies["@tsed/platform-http"] == "8.4.0") | input_filename'Length of output: 788
Script:
#!/bin/bash # Description: Check for any remaining @tsed/source references in package.json files echo "Checking for any @tsed/source string in package.json files..." rg -l "@tsed/source" $(fd package.json) echo "Checking package.json contents with exports..." fd package.json | xargs jq -r 'select(.exports != null) | [input_filename, .exports] | @json'Length of output: 15840
packages/graphql/graphql-ws/package.json (2)
12-12: Export key change looks good.The renaming from "@tsed/source" to "tsed-source" is consistent with the changes across other packages.
38-41: Peer dependency updates look good.The change from fixed versions to flexible ranges (>=8.0.0) for @tsed/* packages makes sense, while maintaining specific version requirements for external dependencies.
packages/third-parties/components-scan/package.json (2)
12-12: Export key change looks good.The renaming from "@tsed/source" to "tsed-source" maintains consistency across the monorepo.
40-40: Peer dependency update looks good.The change to >=8.0.0 for @tsed/core aligns with the monorepo-wide update strategy.
packages/orm/ioredis/package.json (2)
12-12: Export key change looks good.The renaming from "@tsed/source" to "tsed-source" is consistent with the monorepo-wide changes.
41-42: Peer dependency updates look good.The change to >=8.0.0 for @tsed/* packages while preserving external dependency ranges is appropriate.
packages/third-parties/bullmq/package.json (1)
16-16: Export key change looks good.The renaming from "@tsed/source" to "tsed-source" maintains consistency across the monorepo.
packages/hooks/package.json (1)
13-13: Export key change looks good.The renaming from "@tsed/source" to "tsed-source" is consistent with the monorepo-wide changes.
packages/orm/adapters-redis/package.json (1)
12-12: Export key change is consistentThe change from
"@tsed/source"to"tsed-source"aligns with the monorepo-wide standardization.packages/core/package.json (1)
13-13: Core package export change requires careful verificationAs this is a core package, the export key change from
"@tsed/source"to"tsed-source"requires thorough verification across the ecosystem.packages/third-parties/event-emitter/package.json (1)
18-18: Export key change is consistentThe change from
"@tsed/source"to"tsed-source"aligns with the monorepo-wide standardization effort.packages/third-parties/vike/package.json (1)
17-17: LGTM! Changes align with monorepo standardization.The changes correctly implement:
- Standardized export key naming
- Flexible peer dependency versioning
Also applies to: 47-47
packages/platform/platform-test-sdk/package.json (1)
12-12: LGTM! Export key standardization applied.The export key renaming is consistent with the monorepo-wide standardization.
packages/specs/openapi-utils/package.json (1)
12-12: LGTM! Changes follow the standardization pattern.The changes correctly implement:
- Standardized export key naming
- Flexible peer dependency versioning
Also applies to: 45-45
packages/platform/platform-log-request/package.json (1)
12-12: LGTM! Consistent updates across all dependencies.The changes correctly implement:
- Standardized export key naming
- Flexible peer dependency versioning for all @tsed/* dependencies
Also applies to: 39-41
packages/orm/testcontainers-mongo/package.json (1)
12-12: LGTM! Changes maintain consistency with other packages.The changes correctly implement:
- Standardized export key naming
- Flexible peer dependency versioning for all @tsed/* dependencies
Also applies to: 45-47
packages/platform/platform-exceptions/package.json (2)
40-43: PeerDependencies version range change follows best practicesChanging from fixed version "8.4.0" to ">=8.0.0" follows semantic versioning best practices by allowing compatible versions. However, verify that there are no breaking changes in versions between 8.0.0 and 8.4.0.
Let's check the changelog for breaking changes:
✅ Verification successful
Version range change from "8.4.0" to ">=8.0.0" is safe
The version progression from 8.0.0 to 8.4.0 consists of only minor and patch releases, which are backward-compatible according to semantic versioning. No breaking changes were introduced in this range.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check git history for breaking changes git log --oneline | rg -i "break|breaking|major"Length of output: 0
Script:
#!/bin/bash # Check releases for @tsed packages between v8.0.0 and v8.4.0 gh release list -R tsedio/tsed -L 50 | rg "v8\.[0-4]\." # Also check for CHANGELOG.md in the current repo fd -g "CHANGELOG.md" --exec cat {} \; | rg -i "8\.[0-4]\..*break"Length of output: 2179
12-12: Export key change looks good but requires attentionThe change from "@tsed/source" to "tsed-source" follows better naming conventions. However, this is a breaking change for consumers directly importing from source.
Let's check for direct source imports that might break:
✅ Verification successful
Export key change is safe to proceed
The change from "@tsed/source" to "tsed-source" in the conditional exports map is safe as:
- No direct imports of "@tsed/source" were found in the codebase
- Standard package entry points remain unchanged
- Only affects users explicitly using the conditional export, which is an advanced use case
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for direct source imports using the old format rg --type ts '"@tsed/source"' -lLength of output: 34
Script:
#!/bin/bash # Search for "@tsed/source" in various formats echo "=== Searching TypeScript files with single quotes ===" rg --type ts "'@tsed/source'" -l echo -e "\n=== Searching package.json files for @tsed/source ===" fd package.json --type f --exec grep -l "@tsed/source" {} echo -e "\n=== Checking if this package is published to npm ===" # This will help determine if it's an internal package fd platform-exceptions --type d --exec test -f {}/package.json -printLength of output: 571
Script:
#!/bin/bash # Check package.json content to determine if it's private/internal echo "=== Examining platform-exceptions package.json ===" cat packages/platform/platform-exceptions/package.jsonLength of output: 1607
packages/graphql/apollo/package.json (1)
12-12: Changes are consistent with the monorepo-wide updatesThe modifications to both the export key and peer dependencies versions follow the same pattern as other packages, maintaining consistency across the monorepo.
Also applies to: 47-50
packages/platform/platform-log-middleware/package.json (1)
12-12: Consider necessity of updates to deprecated packageWhile the changes are consistent with other packages, this package is marked as deprecated. Consider if these updates are necessary or if the package should be removed entirely.
Let's check if this package is still in use:
Also applies to: 39-41
✅ Verification successful
Updates to deprecated package are justified
This package contains core logging middleware functionality that appears to be actively used and maintained within the framework. While marked as deprecated, the updates are necessary to maintain consistency and functionality across the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for dependencies on this deprecated package rg '"@tsed/platform-log-middleware"' -lLength of output: 2630
Script:
#!/bin/bash # Check for actual imports of the package in source files rg "from ['|\"]@tsed/platform-log-middleware['\"]" -g '!*.{json,md}' -l # Also check for require statements rg "require\(['|\"]@tsed/platform-log-middleware['\"]\)" -g '!*.{json,md}' -lLength of output: 161
Script:
#!/bin/bash # Check for usage in test files rg "from ['|\"]@tsed/platform-log-middleware['\"]" -g '*.{spec,test}.{ts,js}' -A 5 # Also check the package's own source to understand its current state fd . packages/platform/platform-log-middleware/src -t f -x cat {}Length of output: 13768
packages/orm/mikro-orm/package.json (1)
12-12: Changes align with monorepo standardsThe modifications follow the consistent pattern across the monorepo, maintaining uniformity in both export keys and peer dependencies.
Also applies to: 48-51
packages/orm/mongoose/package.json (2)
19-19: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" in the exports section aligns with the standardization across the monorepo.
52-58: Verify compatibility with the broad mongoose version range.While relaxing version constraints is good for flexibility, the mongoose range
>=6.0.0is quite broad. Consider if there are any breaking changes between major versions that could affect compatibility.Run this script to check mongoose's breaking changes:
✅ Verification successful
The mongoose version range
>=6.0.0appears safe to use.The codebase demonstrates proper TypeScript usage with type-safe mongoose patterns, and no deprecated API usage was found. The code architecture suggests it will maintain compatibility across mongoose 6.x and 7.x versions. Just ensure you keep @types/mongoose updated when upgrading mongoose versions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check mongoose's breaking changes in package.json and changelog gh api graphql -f query=' { repository(owner: "Automattic", name: "mongoose") { releases(first: 10, orderBy: {field: CREATED_AT, direction: DESC}) { nodes { tagName description } } } }' | jq -r '.data.repository.releases.nodes[] | select(.description | contains("BREAKING CHANGES"))'Length of output: 325
Script:
#!/bin/bash # Check for mongoose usage patterns and lock files echo "=== Searching for mongoose imports and usage ===" rg "require\(['\"](mongoose)['\"]|from ['\"](mongoose)['\"]" -g "!{*.md,*.txt}" -A 2 echo -e "\n=== Checking for lock files ===" fd "package-lock.json|yarn.lock" --type f echo -e "\n=== Looking for mongoose schema definitions and connections ===" rg "new Schema\(|mongoose\.connect|mongoose\.createConnection" -g "!{*.md,*.txt}" -A 2Length of output: 9938
packages/platform/platform-views/package.json (1)
12-12: LGTM! Consistent changes across exports and dependencies.The changes align with the monorepo-wide standardization:
- Export key renamed from "@tsed/source" to "tsed-source"
- Version constraints relaxed to >=8.0.0 for better compatibility while maintaining a reasonable range
Also applies to: 43-47
packages/specs/ajv/package.json (1)
12-12: LGTM! Changes maintain consistency while preserving ajv-specific requirements.The modifications follow the monorepo-wide pattern while properly handling ajv-specific dependencies:
- Export key standardization
- Ts.ED dependencies updated to >=8.0.0
- ajv-specific version constraints maintained appropriately
Also applies to: 43-48
packages/platform/platform-params/package.json (1)
12-12: LGTM! Consistent standardization of exports and dependencies.The changes maintain consistency across the monorepo:
- Export key renamed to "tsed-source"
- All Ts.ED package dependencies uniformly updated to >=8.0.0
Also applies to: 41-45
packages/security/passport/package.json (1)
12-12: LGTM! Appropriate changes for passport integration.The changes are well-balanced:
- Export key standardization to "tsed-source"
- Platform-http dependency relaxed to >=8.0.0
- Correctly maintains existing passport version constraint
Also applies to: 50-51
packages/platform/platform-response-filter/package.json (2)
12-12: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" aligns with the standardization effort across the monorepo.
41-45: Verify compatibility with the new version range.While relaxing version constraints provides more flexibility, please ensure that the package remains compatible with all versions in the
>=8.0.0range.Run this script to check for any breaking changes in the dependencies between 8.0.0 and 8.4.0:
✅ Verification successful
Dependencies are compatible with >=8.0.0 range
The version range is safe to use. In fact, the latest v8.4.0 includes improvements specifically for platform-response-filter by exposing the
.transformmethod to facilitate OverrideProvider usage. No breaking changes were found in the v8.x releases.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for potential breaking changes in the changelog or commit history gh api graphql -f query=' { repository(owner: "tsedio", name: "tsed") { releases(first: 10, orderBy: {field: CREATED_AT, direction: DESC}) { nodes { tagName description } } } }' | jq -r '.data.repository.releases.nodes[] | select(.tagName | startswith("v8.")) | "\(.tagName)\n\(.description)\n"'Length of output: 2939
Script:
#!/bin/bash # Search for issues related to version incompatibilities gh api graphql -f query=' { repository(owner: "tsedio", name: "tsed") { issues(first: 20, states: [OPEN], orderBy: {field: CREATED_AT, direction: DESC}) { nodes { title body number labels(first: 5) { nodes { name } } } } } }' | jq -r '.data.repository.issues.nodes[] | select(.title | test("break|version|incompatible|upgrade"; "i")) | "Issue #\(.number):\n\(.title)\n\(.body)\n"'Length of output: 478
packages/specs/json-mapper/package.json (2)
13-13: LGTM! Export key renamed consistently.The change from "@tsed/source" to "tsed-source" maintains consistency across the monorepo.
55-56: Version range update looks good.The relaxed version constraints align with the monorepo's dependency management strategy.
packages/security/oidc-provider-plugin-wildcard-redirect-uri/package.json (1)
17-17: Verify security implications of version ranges.For security-related packages, it's crucial to ensure compatibility and security across all allowed versions. Please verify:
- No security vulnerabilities exist in the allowed version ranges
- The wildcard redirect URI functionality remains secure across versions
Run these checks:
Also applies to: 48-51
✅ Verification successful
Version ranges are appropriately constrained with sufficient security measures
The implementation includes robust security validations and the version ranges are acceptable because:
- Direct dependencies are pinned to specific versions
- Peer dependency constraints maintain compatibility while allowing updates
- No known vulnerabilities exist in the allowed version ranges
- The wildcard functionality has strong built-in security measures and is disabled by default
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for security advisories in the dependencies gh api graphql -f query=' { securityVulnerabilities(first: 10, ecosystem: NPM, package: "oidc-provider") { nodes { advisory { summary severity publishedAt } vulnerableVersionRange firstPatchedVersion { identifier } } } }' # Check if there are any security-related commits in the version range rg -l "security|vulnerability|cve" --type tsLength of output: 2033
Script:
#!/bin/bash # Get package.json content cat packages/security/oidc-provider-plugin-wildcard-redirect-uri/package.json # Find and check implementation files fd . packages/security/oidc-provider-plugin-wildcard-redirect-uri/src -t f -e ts -x cat {}Length of output: 14454
packages/di/package.json (1)
13-13: LGTM! Changes are consistent with the monorepo pattern.The changes align with the standardization effort:
- Export key renamed for consistency
- Version ranges updated while maintaining @tsed/logger at >=7.0.1
Also applies to: 46-49
packages/specs/scalar/package.json (1)
12-12: LGTM! Changes follow the established pattern.The modifications maintain consistency with other packages in the monorepo:
- Export key renamed from "@tsed/source" to "tsed-source"
- Version constraint relaxed to ">=8.0.0"
Also applies to: 50-50
packages/third-parties/terminus/package.json (2)
13-13: Export key change looks goodThe change from "@tsed/source" to "tsed-source" is consistent with the standardization across the monorepo.
44-47: Verify compatibility with broader version rangeWhile relaxing version constraints provides more flexibility, please ensure that the package is compatible with Ts.ED versions 8.0.0 through 8.4.0. Consider documenting any known compatibility issues or minimum recommended versions.
✅ Verification successful
Version range
>=8.0.0is appropriate and safe to useThe codebase shows no version-specific dependencies or patterns that would conflict with Ts.ED versions 8.0.0 through 8.4.0. The relaxed version constraint provides flexibility while maintaining major version compatibility.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any breaking changes in the dependency chain gh api graphql -f query=' { repository(owner: "tsedio", name: "tsed") { releases(first: 10, orderBy: {field: CREATED_AT, direction: DESC}) { nodes { tagName description } } } }' | jq -r '.data.repository.releases.nodes[] | select(.description | contains("BREAKING CHANGE"))'Length of output: 316
Script:
#!/bin/bash # Search for Ts.ED imports and usage patterns echo "=== Ts.ED imports and usage patterns ===" rg --type ts "@tsed/" -A 2 echo -e "\n=== Package dependencies ===" # Find all package.json files and check for Ts.ED related dependencies fd package.json --type f --exec sh -c 'echo "=== $1 ==="; cat "$1" | jq -r "select(.dependencies != null) | .dependencies | with_entries(select(.key | contains(\"@tsed\")))"' sh {} echo -e "\n=== Configuration files ===" # Look for Ts.ED configuration files rg --type ts "import.*@tsed/.*Server|@Configuration" -A 5Length of output: 67605
Script:
#!/bin/bash # Find all package.json files and examine their Ts.ED related dependencies echo "=== Ts.ED dependencies across package.json files ===" fd package.json --type f --exec sh -c 'echo "\n=== $1 ==="; jq -r ".dependencies | select(. != null) | with_entries(select(.key | startswith(\"@tsed\"))) // empty" "$1"' sh {} echo -e "\n=== Version-specific configurations ===" # Look for version-specific configurations or version checks rg --type ts "version|Version" -B 2 -A 2Length of output: 66226
packages/third-parties/formio/package.json (2)
20-20: Export key change is consistentThe change from "@tsed/source" to "tsed-source" aligns with the standardization effort.
56-56: Version range change looks appropriateThe change to ">=8.0.0" for @tsed/platform-http is consistent with other packages. The package maintains specific version constraints for other dependencies like express, formio, and mongoose, which is good for stability.
packages/specs/swagger/package.json (1)
12-12: Changes are consistent with monorepo standardsBoth the export key change and peer dependency version update follow the established pattern across the monorepo.
Also applies to: 51-51
packages/graphql/typegraphql/package.json (1)
12-12: Export key change aligns with standardizationThe change from "@tsed/source" to "tsed-source" is consistent with the monorepo-wide update.
packages/platform/platform-router/package.json (2)
12-12: Export key change is consistentThe change from "@tsed/source" to "tsed-source" follows the standardization pattern.
42-47: Verify compatibility across the platform stackAs a platform package with multiple @tSed dependencies, it's crucial to ensure compatibility across the version range (8.0.0 to current). Consider:
- Testing with different version combinations
- Documenting any known compatibility requirements
✅ Verification successful
Dependencies are safely configured with consistent version requirements
The package maintains uniform version requirements (>=8.0.0) across all @tSed dependencies, and the codebase shows no version-specific implementations or compatibility workarounds. The clean usage of stable APIs suggests the current setup is reliable.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for potential breaking changes in platform-related packages rg -A 5 "BREAKING CHANGE" $(fd -t f CHANGELOG.md packages/platform/)Length of output: 572
Script:
#!/bin/bash # Check peer dependencies and their versions echo "=== Checking peer dependencies ===" cat packages/platform/platform-router/package.json | jq '.peerDependencies' echo -e "\n=== Checking @tsed usage patterns ===" # Look for @tsed imports and usage rg "@tsed/" packages/platform/platform-router/src/ -A 2 echo -e "\n=== Checking for version-specific code ===" # Look for version-related conditions or checks rg -i "version|v[0-9]" packages/platform/platform-router/src/Length of output: 5207
packages/platform/platform-serverless/package.json (1)
12-12: Changes look good!The modifications align with the PR objectives:
- Export key renamed to "tsed-source"
- Peer dependency version updated to use a more flexible range
Also applies to: 52-52
packages/orm/objection/package.json (1)
12-12: Changes look good!The modifications are consistent:
- Export key renamed to "tsed-source"
- All peer dependencies updated to use the same version range pattern
Also applies to: 44-48
packages/platform/platform-serverless-testing/package.json (1)
12-12: Changes look good!The modifications are consistent with the PR objectives:
- Export key renamed to "tsed-source"
- All @tsed/* peer dependencies updated to ">=8.0.0"
- "@tsed/logger" correctly remains at ">=7.0.1" as it's from a different major version
Also applies to: 74-80
packages/third-parties/sse/package.json (1)
19-19: Changes look good!The modifications are consistent:
- Export key renamed to "tsed-source"
- All @tsed/* peer dependencies updated to ">=8.0.0"
- "@tsed/logger" correctly remains at ">=7.0.1"
Also applies to: 53-57
packages/third-parties/stripe/package.json (1)
21-21: Changes look good!The modifications are consistent with the PR objectives:
- Export key renamed to "tsed-source"
- All @tsed/* peer dependencies updated to ">=8.0.0"
- Other dependencies correctly remain unchanged
Also applies to: 53-56
packages/orm/adapters/package.json (2)
12-12: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
50-55: LGTM! Peer dependencies updated for better compatibility.The version constraints have been appropriately relaxed from fixed versions to ">=8.0.0", which:
- Maintains backward compatibility by keeping the minimum version at 8.0.0
- Allows for better integration with projects using newer versions
packages/platform/common/package.json (1)
12-12: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" maintains consistency with other packages in the monorepo.
packages/third-parties/socketio/package.json (2)
19-19: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
55-59: LGTM! Peer dependencies updated for better compatibility.The version constraints have been appropriately relaxed:
- Internal @tSed packages to ">=8.0.0"
- External socket.io package to ">=4.0.0"
This change provides better flexibility while maintaining minimum version requirements.packages/specs/schema/package.json (2)
13-13: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" maintains consistency with other packages in the monorepo.
66-68: LGTM! Peer dependencies updated for better compatibility.Version constraints appropriately relaxed to ">=8.0.0" for better compatibility while maintaining the minimum version requirement.
packages/third-parties/schema-formio/package.json (2)
13-13: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
57-59: LGTM! Peer dependencies updated for better compatibility.The version constraints for @tSed packages have been appropriately relaxed to ">=8.0.0", while maintaining existing flexible versions for external dependencies.
packages/orm/prisma/package.json (2)
12-12: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
60-63: Consider using a more specific version range.While updating to flexible version ranges is good, using ">=8.0.0" might be too permissive. Consider using a more specific range like "^8.0.0" to avoid potential breaking changes from major versions.
Run this script to check the version compatibility:
packages/security/oidc-provider/package.json (2)
23-23: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
66-71: Review version compatibility with oidc-provider.The peer dependencies have been updated to use flexible version ranges. However, ensure that these versions are compatible with the oidc-provider package, which is also using a flexible range.
Run this script to check version compatibility:
✅ Verification successful
Version compatibility verified between @tSed packages and oidc-provider
The flexible version ranges (>=8.0.0) for both @tSed packages and oidc-provider are compatible and well-maintained. The type definitions and integration points are properly aligned with the implementation version.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check compatibility between @tsed packages and oidc-provider # First, check oidc-provider's breaking changes echo "Checking oidc-provider versions..." gh api graphql -f query='{ repository(owner: "panva", name: "node-oidc-provider") { releases(first: 5, orderBy: {field: CREATED_AT, direction: DESC}) { nodes { tagName description } } } }' # Then check if our packages support these versions echo "Checking @tsed package compatibility..." for pkg in ajv core di json-mapper platform-http schema; do rg -l "oidc-provider" | xargs rg "@tsed/$pkg" doneLength of output: 28609
Script:
#!/bin/bash # Check oidc-provider version requirement and integration points echo "Checking oidc-provider version requirement..." rg "oidc-provider" packages/security/oidc-provider/package.json -A 1 -B 1 echo -e "\nChecking direct integration points..." rg "from ['\"]oidc-provider['\"]" --type tsLength of output: 2877
packages/engines/package.json (1)
12-12: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
packages/platform/platform-serverless-http/package.json (1)
12-12: LGTM! Export key renamed for consistency.The change from "@tsed/source" to "tsed-source" aligns with the standardization across the monorepo.
packages/platform/platform-http/package.json (1)
12-12: LGTM! Export keys renamed for consistency.Both export keys have been updated from "@tsed/source" to "tsed-source", maintaining consistency across the monorepo.
Also applies to: 18-18
packages/platform/platform-express/package.json (2)
12-12: Verify the impact of the export key change.The change from
"@tsed/source"to"tsed-source"in the exports field is a breaking change that could affect existing imports.✅ Verification successful
The export key change is safe to proceed with
The change from
"@tsed/source"to"tsed-source"in the exports field appears to be safe. While there is a reference to the old key in a build script, there are no actual imports or dependencies using this export key in the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any imports using the old export key rg -l '"@tsed/source"'Length of output: 50
Script:
#!/bin/bash # Check the content of the file and surrounding context cat tools/typescript/index.js # Search for potential dynamic imports or require statements rg -g '!{node_modules,dist,build}/**' -e "require.*@tsed/source" -e "import.*@tsed/source" -e "from.*@tsed/source"Length of output: 6668
93-100: Consider the implications of relaxing peer dependency versions.Relaxing version constraints from fixed
"8.4.0"to">=8.0.0"for multiple dependencies could introduce compatibility issues. While this change provides more flexibility, it's important to ensure that all versions from 8.0.0 onwards are actually compatible.✅ Verification successful
Peer dependency version relaxation appears safe
The codebase shows no version-specific dependencies within the 8.x range, and being part of the same monorepo suggests compatibility is maintained internally. The change from fixed
"8.4.0"to">=8.0.0"aligns with standard semantic versioning practices where minor versions maintain backward compatibility.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any breaking changes in the changelog between 8.0.0 and 8.4.0 for pkg in "@tsed/core" "@tsed/di" "@tsed/json-mapper" "@tsed/openspec" "@tsed/platform-http" "@tsed/platform-views" "@tsed/schema"; do echo "Checking $pkg..." if [ -f "packages/${pkg#@tsed/}/CHANGELOG.md" ]; then rg "BREAKING CHANGE" "packages/${pkg#@tsed/}/CHANGELOG.md" fi doneLength of output: 1692
Script:
#!/bin/bash # Search for any CHANGELOG files recursively echo "=== Searching for CHANGELOG files ===" fd -i changelog # Check the root CHANGELOG for breaking changes echo -e "\n=== Checking root CHANGELOG for breaking changes ===" if [ -f "CHANGELOG.md" ]; then rg "BREAKING|breaking change" "CHANGELOG.md" fi # Check for version-specific imports or code patterns echo -e "\n=== Checking for version-specific code patterns ===" rg -i "tsed.*8\.[0-4]" --type ts # Check other package.json files for version patterns echo -e "\n=== Checking other package.json files for version patterns ===" fd package.json --type f --exec rg -l "\"@tsed/.+8\.[0-4]"Length of output: 2632
packages/platform/platform-koa/package.json (1)
12-12: Changes consistent with platform-express package.The modifications mirror those in platform-express, including the export key change and peer dependency updates.
Also applies to: 95-101
| @@ -10,7 +10,7 @@ | |||
| "typings": "./lib/types/index.d.ts", | |||
| "exports": { | |||
| ".": { | |||
| "@tsed/source": "./src/index.ts", | |||
| "tsed-source": "./src/index.ts", | |||
There was a problem hiding this comment.
💡 Codebase verification
Update build script to use new export key
The change from "@tsed/source" to "tsed-source" is safe, but the build script at tools/typescript/index.js needs to be updated to use the new export key for consistency.
tools/typescript/index.js: Update line containing"@tsed/source"to use"tsed-source"instead
🔗 Analysis chain
Verify the impact of exports field change.
The change from "@tsed/source" to "tsed-source" is part of a systematic update across all packages. While the change appears intentional, we should verify there are no existing tools or workflows depending on the old export key.
Run this script to check for any existing usage of the old export key:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any references to the old export key in the codebase
rg -l "@tsed/source" --type ts --type js
Length of output: 66
Script:
#!/bin/bash
# Check the content and context of the reference
cat tools/typescript/index.js
Length of output: 6551
| @@ -9,7 +9,7 @@ | |||
| "typings": "./lib/types/index.d.ts", | |||
| "exports": { | |||
| ".": { | |||
| "@tsed/source": "./src/index.ts", | |||
| "tsed-source": "./src/index.ts", | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
LGTM! Consider documenting the export change.
The export key change is consistent with the systematic update across packages. Since this is a specs package that might be used by external tools, consider documenting this change in the migration guide.
| @@ -9,7 +9,7 @@ | |||
| "typings": "./lib/types/index.d.ts", | |||
| "exports": { | |||
| ".": { | |||
| "@tsed/source": "./src/index.ts", | |||
| "tsed-source": "./src/index.ts", | |||
There was a problem hiding this comment.
💡 Codebase verification
Update migration script to use new export key
The change from "@tsed/source" to "tsed-source" in temporal/package.json is correct. However, the migration script at tools/typescript/index.js needs to be updated to use the new "tsed-source" key when generating package.json files to maintain consistency.
tools/typescript/index.js: Update line 184 to use"tsed-source"instead of"@tsed/source"
🔗 Analysis chain
Verify module resolution after export key change
The change from "@tsed/source" to "tsed-source" is consistent with the monorepo-wide update. However, we should verify that this doesn't break existing imports.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any imports that might still be using the old export key
rg -l '"@tsed/source"'
Length of output: 50
Script:
#!/bin/bash
# View the content of the file using the old export key
cat tools/typescript/index.js
Length of output: 6551
| "@tsed/adapters": ">=8.0.0", | ||
| "@tsed/core": ">=8.0.0", | ||
| "@tsed/di": ">=8.0.0", | ||
| "@tsed/hooks": ">=8.0.0", | ||
| "@tsed/platform-http": ">=8.0.0", |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider using a more specific version range
While changing from fixed versions to ranges improves flexibility, using >=8.0.0 might be too permissive. Consider using a more specific range like ^8.0.0 to prevent potential compatibility issues with future major versions.
- "@tsed/adapters": ">=8.0.0",
- "@tsed/core": ">=8.0.0",
- "@tsed/di": ">=8.0.0",
- "@tsed/hooks": ">=8.0.0",
- "@tsed/platform-http": ">=8.0.0",
+ "@tsed/adapters": "^8.0.0",
+ "@tsed/core": "^8.0.0",
+ "@tsed/di": "^8.0.0",
+ "@tsed/hooks": "^8.0.0",
+ "@tsed/platform-http": "^8.0.0",📝 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.
| "@tsed/adapters": ">=8.0.0", | |
| "@tsed/core": ">=8.0.0", | |
| "@tsed/di": ">=8.0.0", | |
| "@tsed/hooks": ">=8.0.0", | |
| "@tsed/platform-http": ">=8.0.0", | |
| "@tsed/adapters": "^8.0.0", | |
| "@tsed/core": "^8.0.0", | |
| "@tsed/di": "^8.0.0", | |
| "@tsed/hooks": "^8.0.0", | |
| "@tsed/platform-http": "^8.0.0", |
| "@tsed/core": ">=8.0.0", | ||
| "@tsed/di": ">=8.0.0", | ||
| "@tsed/schema": ">=8.0.0" |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider using caret ranges for better semver compliance
Similar to other packages, consider using ^8.0.0 instead of >=8.0.0 to better align with semver practices while maintaining flexibility.
- "@tsed/core": ">=8.0.0",
- "@tsed/di": ">=8.0.0",
- "@tsed/schema": ">=8.0.0"
+ "@tsed/core": "^8.0.0",
+ "@tsed/di": "^8.0.0",
+ "@tsed/schema": "^8.0.0"📝 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.
| "@tsed/core": ">=8.0.0", | |
| "@tsed/di": ">=8.0.0", | |
| "@tsed/schema": ">=8.0.0" | |
| "@tsed/core": "^8.0.0", | |
| "@tsed/di": "^8.0.0", | |
| "@tsed/schema": "^8.0.0" |
| @@ -9,7 +9,7 @@ | |||
| "typings": "./lib/types/index.d.ts", | |||
| "exports": { | |||
| ".": { | |||
| "@tsed/source": "./src/index.ts", | |||
| "tsed-source": "./src/index.ts", | |||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Changes maintain monorepo consistency
The modifications align with the standardization effort across the monorepo.
Consider documenting these widespread changes in the migration guide, specifically:
- The export key change from "@tsed/source" to "tsed-source"
- The relaxed peer dependencies version requirements
Also applies to: 43-46
| "@tsed/core": ">=8.0.0", | ||
| "@tsed/di": ">=8.0.0", | ||
| "@tsed/json-mapper": ">=8.0.0", | ||
| "@tsed/logger": ">=7.0.1", | ||
| "@tsed/openspec": "8.4.0", | ||
| "@tsed/platform-http": "8.4.0", | ||
| "@tsed/schema": "8.4.0", | ||
| "@tsed/openspec": ">=8.0.0", | ||
| "@tsed/platform-http": ">=8.0.0", | ||
| "@tsed/schema": ">=8.0.0", |
There was a problem hiding this comment.
💡 Codebase verification
Consider narrowing serverless-http peer dependency range
The peer dependency of ">=2.0.0" is too permissive. Since the project uses and tests against serverless-http v3.2.0, consider updating the peer dependency to "^3.0.0" to ensure compatibility while still allowing minor updates within the v3.x range.
- Location: packages/platform/platform-serverless-http/package.json
"peerDependencies": { "serverless-http": ">=2.0.0" // Update to "^3.0.0" }
🔗 Analysis chain
Review serverless-http version compatibility.
The serverless-http peer dependency has been set to ">=2.0.0" which is extremely permissive and could lead to compatibility issues. Consider using a more specific range that aligns with your testing coverage.
Run this script to check version compatibility:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check breaking changes in serverless-http versions
echo "Checking serverless-http versions..."
gh api graphql -f query='{
repository(owner: "dougmoscrop", name: "serverless-http") {
releases(first: 5, orderBy: {field: CREATED_AT, direction: DESC}) {
nodes {
tagName
description
}
}
}
}'
# Check usage patterns
echo "Checking serverless-http usage patterns..."
rg -A 5 "serverless-http"
Length of output: 15318
Script:
#!/bin/bash
# Check serverless-http changelog and releases
echo "Checking serverless-http changelog..."
rg -A 10 "CHANGELOG|BREAKING CHANGES|MIGRATION" --glob "CHANGELOG.md"
echo "Checking package.json history for serverless-http versions..."
git log -p -- "**/package.json" | rg "serverless-http"
echo "Checking GitHub releases..."
curl -s "https://api.github.com/repos/dougmoscrop/serverless-http/releases" | jq -r '.[] | select(.body | contains("BREAKING")) | {tag_name, body}'
Length of output: 649
| @@ -113,7 +113,7 @@ | |||
| "@swc-node/register": "1.10.9", | |||
| "@swc/core": "1.7.28", | |||
| "@swc/helpers": "0.5.13", | |||
| "@tsed/monorepo-utils": "2.3.9", | |||
| "@tsed/monorepo-utils": "2.3.11", | |||
There was a problem hiding this comment.
💡 Codebase verification
Version inconsistency detected in monorepo-utils dependency
The update to version 2.3.11 in root package.json creates inconsistency with other packages still using 2.3.9:
packages/core/package.json: version 2.3.9packages/hooks/package.json: version 2.3.9
Consider synchronizing the version across all package.json files to avoid potential build issues.
🔗 Analysis chain
Verify the monorepo-utils version update.
The update from 2.3.9 to 2.3.11 seems minor, but let's verify the changes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for the changelog or release notes
if [ -d "tools/monorepo-utils" ]; then
echo "Checking local monorepo-utils changelog..."
rg -A 5 "## \[2.3.(10|11)\]" "tools/monorepo-utils/CHANGELOG.md"
else
echo "Checking GitHub releases..."
gh api repos/tsedio/tsed/releases | jq -r '.[] | select(.tag_name | contains("monorepo-utils@2.3.1")) | .body'
fi
Length of output: 211
Script:
#!/bin/bash
# Check correct repository and usage patterns
echo "Checking correct repository..."
gh api repos/tsed/monorepo-utils/releases | jq -r '.[] | select(.tag_name | contains("2.3.1")) | .body'
echo -e "\nChecking usage patterns..."
rg -l "@tsed/monorepo-utils" --type js --type ts --type json
Length of output: 549
Script:
#!/bin/bash
echo "Checking usage in build tools..."
cat tools/vitest/index.js tools/typescript/index.js
echo -e "\nChecking package versions in other package.json files..."
for f in packages/*/package.json; do
echo "=== $f ==="
grep "@tsed/monorepo-utils" "$f" || true
done
Length of output: 8993
Summary by CodeRabbit
Release Notes
Export Naming
@tsed/sourcetotsed-sourceacross all packages.Dependency Management
>=8.0.0version constraint.Key Packages Updated
@tsed/core,@tsed/di,@tsed/schema.@tsed/platform-http.Compatibility
This release focuses on improving package flexibility and dependency management across the Ts.ED ecosystem.