Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: strict validate deps #720

Merged
merged 2 commits into from
Oct 26, 2024
Merged

feat: strict validate deps #720

merged 2 commits into from
Oct 26, 2024

Conversation

elrrrrrrr
Copy link
Member

@elrrrrrrr elrrrrrrr commented Oct 24, 2024

During the sync process, dependency installation errors may occur due to incorrect timing or incorrect declaration.

  1. ⚙️ Added strictValidatePackageDeps configuration, disabled by default.
  2. 🔄 In publish process, if the dependencies for the current version do not exist, it will be interrupted.
  3. 📦 In synch process, will automatically enter the queue to wait for the next synchronization attempt (up to 3 retries).
  4. ♻️ Packages that have already been published or synchronized will not be affected.

在版本同步时,由于同步时机或自身依赖声明错误,导致依赖安装报错。

  1. ⚙️ 新增 strictValidatePackageDeps 配置,默认关闭
  2. 🔄 在包发布时,如果当前版本的 dependencies 不存在,则中断发布
  3. 📦 在包同步时,如果校验未通过,则中断发布流程,自动进入队列等待下次同步(最多重试3次)
  4. ♻️ 已发布、同步的包不受影响

Summary by CodeRabbit

Release Notes

  • New Features

    • Introduced strict validation for package dependencies during publishing and synchronization.
    • Added a new configuration option for enforcing dependency validation.
  • Bug Fixes

    • Enhanced error handling for dependency validation failures, allowing for task retries.
  • Tests

    • Added new test cases to ensure proper validation of package dependencies under strict settings.
    • Created a new test suite for handling invalid dependencies in package synchronization.
  • Chores

    • Updated logging for package synchronization processes to improve clarity and error tracking.

@elrrrrrrr elrrrrrrr requested review from fengmk2 and killagu October 24, 2024 05:54
Copy link
Contributor

coderabbitai bot commented Oct 24, 2024

Walkthrough

The changes introduce significant enhancements to the package management system, focusing on dependency validation. A new method _checkPackageDepsVersion is added to PackageManagerService to validate package dependencies. The publish method is updated to conditionally call this validation based on a new configuration property strictValidatePackageDeps. The PackageSyncerService also receives updates for error handling during dependency validation. New tests are added to ensure that the system behaves correctly when invalid dependencies are encountered, alongside the introduction of a new JSON fixture representing a package with invalid dependencies.

Changes

File Change Summary
app/core/service/PackageManagerService.ts - Added method _checkPackageDepsVersion for validating package dependencies.
- Updated publish method to conditionally call _checkPackageDepsVersion.
- Modified imports to include assert and p-map, and added BadRequestError.
app/core/service/PackageSyncerService.ts - Updated executeTask method for enhanced error handling of BadRequestError.
- Refined logic for syncing download data and updated syncDeletePkg method with logging.
app/port/config.ts - Added optional property strictValidatePackageDeps to CnpmcoreConfig.
config/config.default.ts - Introduced strictValidatePackageDeps property initialized to false in cnpmcoreConfig.
test/core/service/PackageManagerService/publish.test.ts - Added test case for publish() to check strict validation of dependencies.
test/core/service/PackageSyncerService/executeTask.test.ts - Introduced new test suite for validating dependencies in PackageSyncerService.
test/fixtures/registry.npmjs.org/invalid-deps.json - Added new JSON fixture for a package with invalid dependencies.

Possibly related PRs

  • feat: sync missing acceptDependencies on abbreviated format #691: The changes in PackageManagerService.ts related to the addition of the acceptDependencies property are relevant as they modify the same file and involve handling package metadata, which is closely related to the dependency validation introduced in the main PR.

Poem

🐰 In the garden of code, where packages bloom,
A rabbit hops by, dispelling the gloom.
With dependencies checked, and errors in sight,
Publishing packages now feels just right!
So let’s raise a cheer, for validation's new song,
In the world of our code, where we all belong! 🌼


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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@elrrrrrrr elrrrrrrr added the enhancement New feature or request label Oct 24, 2024
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 8

🧹 Outside diff range and nitpick comments (5)
test/fixtures/registry.npmjs.org/invalid-deps.json (2)

40-43: Ensure timestamps are consistent with test requirements.

The timestamps are set to October 2024, which is appropriate for current testing. However, consider:

  1. Using static/deterministic timestamps for consistent test behavior
  2. Adding a comment explaining why these specific timestamps were chosen
   "time": {
-    "created": "2024-10-24T02:54:18.513Z",
-    "1.0.0": "2024-10-24T02:54:18.686Z",
-    "modified": "2024-10-24T02:54:18.896Z"
+    "created": "2024-01-01T00:00:00.000Z",  // Static timestamp for consistent testing
+    "1.0.0": "2024-01-01T00:00:00.000Z",    // Static timestamp for consistent testing
+    "modified": "2024-01-01T00:00:00.000Z"   // Static timestamp for consistent testing
   },

46-48: Consider adding test-specific README content.

The current README shows an error state. Consider adding minimal README content to:

  1. Document the purpose of this test fixture
  2. Help other developers understand how to use it in tests
-  "readme": "ERROR: No README data found!",
-  "readmeFilename": ""
+  "readme": "# Invalid Dependencies Test Fixture\n\nThis package contains deliberately invalid dependencies for testing dependency validation features.",
+  "readmeFilename": "README.md"
test/core/service/PackageManagerService/publish.test.ts (1)

116-138: Add test coverage for valid dependencies scenario.

The test suite only covers the rejection case for invalid dependencies. Consider adding a test case that verifies the publish succeeds when dependencies are valid and strict validation is enabled.

Here's a suggested test case to add:

    it('should publish successfully with valid deps when strict validation enabled', async () => {
      mock(app.config.cnpmcore, 'strictValidatePackageDeps', true);
      const { packageId } = await packageManagerService.publish({
        dist: {
          localFile: TestUtil.getFixtures('registry.npmjs.org/pedding/-/pedding-1.1.0.tgz'),
        },
        tags: [''],
        scope: '',
        name: 'pedding',
        description: 'pedding description',
        packageJson: {
          name: 'pedding',
          version: '1.1.0',
          dependencies: {
            // Add a known valid dependency here
            'lodash': '^4.0.0'
          }
        },
        readme: '',
        version: '1.1.0',
        isPrivate: false,
      }, publisher);
      const pkgVersion = await packageRepository.findPackageVersion(packageId, '1.1.0');
      assert(pkgVersion);
      assert.equal(pkgVersion.version, '1.1.0');
    });
app/port/config.ts (1)

174-177: Enhance documentation for the new configuration option.

The implementation looks good, but the documentation could be more comprehensive to help users understand the implications of enabling this option.

Consider expanding the JSDoc comment to include:

  /**
-  * strictly enforces/validates dependencies version when publish or sync
+  * Strictly enforces/validates dependencies version when publishing or syncing packages.
+  * When enabled:
+  * - Publishing will be interrupted if dependencies for the current version are not found
+  * - Failed sync operations will queue the package for up to 3 retry attempts
+  * @default false
   */
  strictValidatePackageDeps?: boolean,
config/config.default.ts (1)

62-62: Add documentation for the new configuration option.

The new configuration option is well-placed near other validation flags. Consider adding a code comment to document its purpose and impact on package dependency validation during sync and publish operations.

+  // When enabled, strictly validates package dependencies during sync and publish operations
   strictValidatePackageDeps: false,
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 2b812a1 and ec55a48.

📒 Files selected for processing (7)
  • app/core/service/PackageManagerService.ts (4 hunks)
  • app/core/service/PackageSyncerService.ts (2 hunks)
  • app/port/config.ts (1 hunks)
  • config/config.default.ts (1 hunks)
  • test/core/service/PackageManagerService/publish.test.ts (1 hunks)
  • test/core/service/PackageSyncerService/executeTask.test.ts (1 hunks)
  • test/fixtures/registry.npmjs.org/invalid-deps.json (1 hunks)
🧰 Additional context used
🪛 GitHub Check: test-mysql57-fs-nfs (22, ubuntu-latest)
app/core/service/PackageManagerService.ts

[failure] 995-995:
A space is required after '['


[failure] 995-995:
A space is required before ']'

🪛 GitHub Check: test-mysql57-fs-nfs (20, ubuntu-latest)
app/core/service/PackageManagerService.ts

[failure] 995-995:
A space is required after '['


[failure] 995-995:
A space is required before ']'

🪛 GitHub Check: test-mysql57-fs-nfs (18, ubuntu-latest)
app/core/service/PackageManagerService.ts

[failure] 995-995:
A space is required after '['


[failure] 995-995:
A space is required before ']'

🔇 Additional comments (8)
test/fixtures/registry.npmjs.org/invalid-deps.json (2)

17-28: LGTM: Integrity and signature data look valid.

The test fixture correctly includes:

  • SHA512 integrity hash
  • SHA1 shasum
  • NPM registry tarball URL
  • Package signatures with keyid and signature

9-10: Verify test coverage for all invalid dependency scenarios.

The test fixture includes two types of invalid dependencies:

  1. "invalid-semver": "@*(5895jk!" - Invalid semver syntax
  2. "invalid-tag": "gutu" - Invalid tag/version

Consider adding more edge cases to ensure comprehensive validation testing:

  • Empty version string
  • Malformed ranges (e.g., ">=1.0.0 <=")
  • Non-string values
✅ Verification successful

Let me fix the syntax error in the shell script and try a different approach to verify the test coverage.

This will help us:

  1. Find all test fixtures that contain dependency definitions
  2. Identify test files related to dependency validation to understand the existing test coverage

Let me check the content of some relevant test fixtures to understand the existing test coverage for invalid dependencies.

This will help us understand:

  1. What other dependency validation test cases already exist
  2. Where the strictValidatePackageDeps feature is being tested
  3. Whether we need additional test cases in invalid-deps.json

Let me check the test files that use strictValidatePackageDeps to understand how the feature is being tested.

This will help us understand:

  1. How strictValidatePackageDeps is being used in tests
  2. What validation scenarios are already covered
  3. Whether our new test fixture complements existing test cases

Based on the test files and fixtures analyzed, I can now provide a final response about the test coverage for invalid dependency scenarios.

The invalid-deps.json test fixture provides good coverage for invalid dependency validation

The current test fixture with two invalid dependency cases ("invalid-semver": "@*(5895jk!" and "invalid-tag": "gutu") is sufficient because:

  1. The test files show that strictValidatePackageDeps validation is tested in both package publishing (PackageManagerService/publish.test.ts) and package syncing (PackageSyncerService/executeTask.test.ts) scenarios
  2. The invalid dependency patterns cover both malformed semver syntax and invalid tag/version formats
  3. Additional edge cases like empty strings or non-string values would be caught by the same validation logic, as they would fail semver parsing similarly

The test fixture aligns well with the existing test infrastructure and provides appropriate test cases for the strictValidatePackageDeps feature.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if there are other test fixtures with invalid dependencies
# to ensure we're not duplicating test cases

# Search for other test fixtures with invalid dependency patterns
rg -l '"dependencies":\s*{[^}]*["\''][^"\'':]+["\'\']\s*:\s*["\''][^0-9A-Za-z\^~>=<\s][^"\'\']*["\'\']' test/fixtures/

Length of output: 93


Script:

#!/bin/bash
# Search for files containing "dependencies" in test fixtures
rg -l '"dependencies"' test/fixtures/

# Also search for any test files related to dependency validation
fd -e js -e json . test/ -x grep -l "dependencies\|validateDeps\|strictValidatePackageDeps"

Length of output: 3264


Script:

#!/bin/bash
# Check content of test fixtures that might contain dependency validation cases
echo "=== cnpmcore-test-sync-dependencies.json ==="
cat test/fixtures/registry.npmjs.org/cnpmcore-test-sync-dependencies.json

echo -e "\n=== accept-dependencies-module-cnpmsync.json ==="
cat test/fixtures/registry.npmjs.org/accept-dependencies-module-cnpmsync.json

# Also let's check if there are any test files specifically for dependency validation
rg -l "strictValidatePackageDeps" test/

Length of output: 9287


Script:

#!/bin/bash
# Check the test files that use strictValidatePackageDeps
echo "=== PackageManagerService/publish.test.ts ==="
cat test/core/service/PackageManagerService/publish.test.ts | grep -A 10 -B 10 "strictValidatePackageDeps"

echo -e "\n=== PackageSyncerService/executeTask.test.ts ==="
cat test/core/service/PackageSyncerService/executeTask.test.ts | grep -A 10 -B 10 "strictValidatePackageDeps"

Length of output: 2851

test/core/service/PackageManagerService/publish.test.ts (1)

115-115: LGTM! Well-integrated test case.

The new test case maintains consistency with the existing test suite structure and properly utilizes the shared test utilities and setup/teardown hooks.

config/config.default.ts (1)

62-62: LGTM! The configuration change looks good.

The new configuration option:

  • Is correctly typed through the CnpmcoreConfig interface
  • Has a safe default value of false for backward compatibility
  • Is logically placed near other validation-related settings
  • Aligns with the PR objectives for enhancing dependency validation
test/core/service/PackageSyncerService/executeTask.test.ts (1)

2556-2570: LGTM on test setup.

The test setup with mock data and HTTP client configuration is well structured and follows the testing patterns used throughout the file.

app/core/service/PackageSyncerService.ts (1)

365-366: 🛠️ Refactor suggestion

Simplify conditional expressions for clarity

The conditionals for skipDependencies and syncUpstream can be simplified to improve readability by removing unnecessary operators.

Apply this diff to simplify the expressions:

-const skipDependencies = taskQueueInHighWaterState ? true : !!originSkipDependencies;
+const skipDependencies = taskQueueInHighWaterState || !!originSkipDependencies;

-const syncUpstream = !!(!taskQueueInHighWaterState && this.config.cnpmcore.sourceRegistryIsCNpm && this.config.cnpmcore.syncUpstreamFirst && registry.name === PresetRegistryName.default);
+const syncUpstream = !taskQueueInHighWaterState && this.config.cnpmcore.sourceRegistryIsCNpm && this.config.cnpmcore.syncUpstreamFirst && registry.name === PresetRegistryName.default;

Likely invalid or redundant comment.

app/core/service/PackageManagerService.ts (2)

106-108: Changes to 'publish' method enhance dependency validation.

The addition of strict dependency validation based on the strictValidatePackageDeps configuration improves the publishing process by ensuring that all dependencies are valid before publishing.


987-1006: Addition of '_checkPackageDepsVersion' method is well-implemented.

The new _checkPackageDepsVersion method correctly validates the versions of the package dependencies and handles exceptions appropriately.

🧰 Tools
🪛 GitHub Check: test-mysql57-fs-nfs (22, ubuntu-latest)

[failure] 995-995:
A space is required after '['


[failure] 995-995:
A space is required before ']'

🪛 GitHub Check: test-mysql57-fs-nfs (20, ubuntu-latest)

[failure] 995-995:
A space is required after '['


[failure] 995-995:
A space is required before ']'

🪛 GitHub Check: test-mysql57-fs-nfs (18, ubuntu-latest)

[failure] 995-995:
A space is required after '['


[failure] 995-995:
A space is required before ']'

@elrrrrrrr elrrrrrrr force-pushed the strict-validate-deps branch from ec55a48 to 8df2857 Compare October 24, 2024 09:31
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Outside diff range and nitpick comments (3)
app/core/service/PackageManagerService.ts (2)

1001-1001: Enhance error message clarity.

The current error message could be more descriptive about the validation failure.

Consider this improvement:

-        throw new BadRequestError(`deps ${fullname}@${spec} not found`);
+        throw new BadRequestError(`Package dependency ${fullname}@${spec} was not found in the registry. Please verify the package name and version specification.`);

1003-1005: Document concurrency limit rationale.

The concurrency limit of 12 for parallel dependency validation seems arbitrary. Consider adding a comment explaining the rationale for this specific value or make it configurable.

    }, {
-      concurrency: 12,
+      // Limit concurrent validations to avoid overwhelming the registry
+      // TODO: Consider making this configurable via config
+      concurrency: 12,
    });
test/core/service/PackageSyncerService/executeTask.test.ts (1)

2578-2579: Uncomment task validation assertions.

These assertions appear to be intentionally commented out but are important for validating the task state after execution.

-        // assert(!await TaskModel.findOne({ taskId: task.taskId }));
-        // assert(await HistoryTaskModel.findOne({ taskId: task.taskId }));
+        assert(!await TaskModel.findOne({ taskId: task.taskId }));
+        assert(await HistoryTaskModel.findOne({ taskId: task.taskId }));
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between ec55a48 and 8df2857.

📒 Files selected for processing (7)
  • app/core/service/PackageManagerService.ts (4 hunks)
  • app/core/service/PackageSyncerService.ts (2 hunks)
  • app/port/config.ts (1 hunks)
  • config/config.default.ts (1 hunks)
  • test/core/service/PackageManagerService/publish.test.ts (1 hunks)
  • test/core/service/PackageSyncerService/executeTask.test.ts (1 hunks)
  • test/fixtures/registry.npmjs.org/invalid-deps.json (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
  • app/port/config.ts
  • config/config.default.ts
  • test/core/service/PackageManagerService/publish.test.ts
  • test/fixtures/registry.npmjs.org/invalid-deps.json
🔇 Additional comments (4)
app/core/service/PackageManagerService.ts (1)

106-108: LGTM! Clean integration of dependency validation.

The conditional validation is well-placed and aligns with the feature's opt-in nature.

test/core/service/PackageSyncerService/executeTask.test.ts (1)

2585-2586: ⚠️ Potential issue

Fix package name in model query.

The package name in the model query ('invalid-pkgs') doesn't match the package name used in the test ('invalid-deps').

-        const model = await PackageModel.findOne({ scope: '', name: 'invalid-pkgs' });
+        const model = await PackageModel.findOne({ scope: '', name: 'invalid-deps' });

Likely invalid or redundant comment.

app/core/service/PackageSyncerService.ts (2)

Line range hint 363-372: Logic for Task Queue High Water State is Correct

The implementation for handling the task queue's high water state by adjusting skipDependencies and syncUpstream is appropriate and enhances resource management during peak loads.


734-741: Set task.error before Logging

In the error handling block, task.error is being logged but may not have been set, which could result in logging undefined. Ensure that task.error is assigned before the logging statement.

Apply this diff to set task.error:

+      task.error = lastErrorMessage;
       if (err.name === 'BadRequestError') {
         // 由于当前版本的依赖不满足,尝试重试
         // 默认会在当前队列最后重试
         this.logger.info('[PackageSyncerService.executeTask:fail-validate-deps] taskId: %s, targetName: %s, %s',
           task.taskId, task.targetName, task.error);
         await this.taskService.retryTask(task, logs.join('\n'));
         return;
       }

const pkgVersion = await this.packageVersionService.getVersion(npa(`${fullname}@${spec}`));
assert(pkgVersion);
} catch (e) {
throw new BadRequestError(`deps ${fullname}@${spec} not found`);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

失败以后这个 job 走默认的重试逻辑吗?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

嗯 是的 默认的失败逻辑会自动放到队列最后 + 最大次数限制。
主要针对场景是 monorepo 并发发包同步,发布期间查询失败。

Copy link

codecov bot commented Oct 24, 2024

Codecov Report

Attention: Patch coverage is 95.23810% with 2 lines in your changes missing coverage. Please review.

Project coverage is 96.46%. Comparing base (d6f0e1d) to head (fd428b4).
Report is 2 commits behind head on master.

Files with missing lines Patch % Lines
app/core/service/PackageManagerService.ts 92.59% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #720      +/-   ##
==========================================
- Coverage   96.46%   96.46%   -0.01%     
==========================================
  Files         188      188              
  Lines       18803    18844      +41     
  Branches     2463     2481      +18     
==========================================
+ Hits        18139    18178      +39     
- Misses        664      666       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (1)
test/core/service/PackageSyncerService/executeTask.test.ts (1)

2556-2570: LGTM! Consider adding descriptive comments.

The test suite setup is well structured with proper mocking of HTTP responses and fixtures. Consider adding JSDoc comments to describe the test suite's purpose and the invalid-deps test data structure.

Add descriptive comments like:

+    /**
+     * Test suite for strictValidatePackageDeps feature
+     * Validates package dependency validation during sync
+     */
     describe('strictValidatePackageDeps = true', async () => {
+      // Setup test fixtures and mock responses for invalid-deps package
+      // The package contains intentionally invalid dependencies for testing
       beforeEach(async () => {
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 8df2857 and fd428b4.

📒 Files selected for processing (2)
  • test/core/service/PackageManagerService/publish.test.ts (1 hunks)
  • test/core/service/PackageSyncerService/executeTask.test.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • test/core/service/PackageManagerService/publish.test.ts

@fengmk2 fengmk2 merged commit 12650ac into master Oct 26, 2024
12 of 13 checks passed
@fengmk2 fengmk2 deleted the strict-validate-deps branch October 26, 2024 11:58
fengmk2 pushed a commit that referenced this pull request Oct 26, 2024
[skip ci]

## [3.65.0](v3.64.0...v3.65.0) (2024-10-26)

### Features

* strict validate deps ([#720](#720)) ([12650ac](12650ac))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants