test: trim redundant e2e tests, move pure logic to unit specs by davidfirst · Pull Request #10651 · teambit/bit

davidfirst · 2026-08-20T21:18:42Z

This PR reduces the number of slow e2e tests. The work goes file by file. Each commit covers one e2e file.

Remove e2e tests that a unit spec already covers.
Remove e2e tests that repeat the same code path as a sibling test.
Move tests of pure functions to unit specs. Example: main-file resolution now has a unit spec (determine-main-file.spec.ts) with 9 tests.
Keep all tests that need a real workspace or scope.

Done so far: add.e2e.ts (24 to 13 tests), config.e2e.ts (13 to 11 tests). More commits will follow on this branch.

…file unit spec

qodo-free-for-open-source-projects · 2026-08-20T21:19:47Z

PR Summary by Qodo

Tests: trim redundant add/config e2e coverage; add determineMainFile unit specs

🧪 Tests 🕐 10-20 Minutes

AI Description

• Remove redundant/overlapping e2e cases in bit add and bit config suites to reduce runtime.
• Add focused unit coverage for determineMainFile() main-file resolution strategies.
• Simplify e2e assertions where coverage is already exercised by remaining tests.

Diagram

graph TD
  E2EAdd(["e2e/commands/add.e2e.ts"]) --> CLI["bit CLI"] --> AddComp["AddComponents"] --> DMF["determineMainFile()"]
  E2EConfig(["e2e/commands/config.e2e.ts"]) --> CLI
  UnitSpec(["scopes/component/tracker/determine-main-file.spec.ts"]) --> DMF

High-Level Assessment

The approach is appropriate: keep e2e coverage for behaviors requiring a real workspace/CLI, and move deterministic strategy logic (main-file resolution) into fast unit specs to reduce suite time. Alternatives like keeping all scenarios as e2e or introducing a mid-level integration harness would be slower or add more framework surface area without clear benefit here.

Files changed (3) +87 / -110

Tests (3) +87 / -110

add.e2e.tsRemove redundant 'bit add' e2e cases (main-file + invalid id/name) +1/-88

Remove redundant 'bit add' e2e cases (main-file + invalid id/name)

• Drops multiple 'bit add' e2e tests that duplicate existing validation or are better covered at the logic level (e.g., missing main file, invalid name/id, multiple index-file main resolution, bitmap sorting). Simplifies the gitignore scenario by removing redundant output/bitmap presence assertions while keeping the key file-filtering check.

e2e/commands/add.e2e.ts

config.e2e.tsRemove 'bit config' git propagation e2e block +0/-22

Remove 'bit config' git propagation e2e block

• Eliminates the e2e suite section that validated config precedence/propagation via git config layers, keeping the remaining local workspace/scope config tests intact. This reduces slow/permission-sensitive git-dependent coverage.

e2e/commands/config.e2e.ts

determine-main-file.spec.tsAdd unit spec for 'determineMainFile()' resolution strategies +86/-0

Add unit spec for 'determineMainFile()' resolution strategies

• Introduces a dedicated unit test suite covering the main-file selection strategies: no-match error, single-file selection, closest index preference, immediate-dir filename fallback, Angular entry point, preservation of existing component-map mainFile, and user-specified main file behavior (present vs missing). This replaces several slower e2e scenarios with direct logic validation.

scopes/component/tracker/determine-main-file.spec.ts

qodo-free-for-open-source-projects · 2026-08-20T21:24:06Z

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

1. Error details no longer tested 🐞 Bug ⚙ Maintainability

Description

The replacement no-main-file unit test accepts any MissingMainFile instance, so regressions that
report the wrong component ID, expected main-file pattern, file list, or user-facing message now
pass. The removed e2e assertion constructed the expected component-specific error, while production
still builds those details separately from the exception type.

Code

scopes/component/tracker/determine-main-file.spec.ts[22]
+      expect(() => determineMainFile(addedComponent, null)).to.throw(MissingMainFile);

Evidence
The production function independently assembles and passes three error arguments, and
MissingMainFile stores them and formats the displayed message. A class-only assertion cannot
detect incorrect values in any of those paths.
scopes/component/tracker/determine-main-file.ts[38-43]
components/legacy/bit-map/exceptions/missing-main-file.ts[10-18]
scopes/component/tracker/determine-main-file.spec.ts[18-23]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The replacement unit test verifies only the `MissingMainFile` class, losing coverage of the component-specific error details that the removed e2e test checked.
## Issue Context
`determineMainFile()` supplies the component ID, expected main-file pattern, and candidate files to `MissingMainFile`; these values determine its user-facing message.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[18-23]
- scopes/component/tracker/determine-main-file.ts[38-43]
- components/legacy/bit-map/exceptions/missing-main-file.ts[10-18]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Depth validation branch untested 🐞 Bug ⚙ Maintainability

Description

The renamed test claims to cover any non-positive-integer depth but still passes only 0, so it
exercises the < 1 branch while the distinct Number.isInteger() rejection for abc and 1.5 now
has no test. A regression that accepts nonnumeric or fractional depths would therefore pass this
suite despite violating the command contract.

Code

e2e/commands/import.e2e.ts[R483-486]

+      it('should error when --dependencies-depth is not a positive integer', () => {
  const output = helper.general.runWithTryCatch(
    `bit import ${helper.scopes.remote}/comp1 --dependencies --dependencies-depth 0`
  );

Evidence

The remaining test invokes only depth 0, whereas command parsing has a separate
Number.isInteger() condition needed to reject both NaN from abc and fractional values such as
1.5; the PR deleted the only shown cases exercising those inputs.

e2e/commands/import.e2e.ts[483-488]
scopes/scope/importer/import.cmd.ts[324-331]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The consolidated dependencies-depth test only supplies zero, leaving the non-integer validation path uncovered while claiming all invalid positive-integer inputs are tested.
## Issue Context
`ImportCmd.report()` converts the option with `Number()` and rejects it using two distinct checks: `!Number.isInteger(...)` and `< 1`. Keep zero coverage and add at least one non-integer input (preferably both nonnumeric and fractional cases), either here or in a focused unit spec for the parser.
## Fix Focus Areas
- e2e/commands/import.e2e.ts[483-488]
- scopes/scope/importer/import.cmd.ts[324-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Test library becomes runtime peer 🐞 Bug ⚙ Maintainability

Description

Adding the Chai-only spec causes @teambit/tracker to declare an exact chai@5.2.1 peer, so
downstream runtime consumers must resolve a test framework that tracker production code never uses.
The repository classifies **/*.spec.ts as dev files, and comparable component specs keep Chai in
devDependencies, so this generated peer is an incorrect dependency classification.

Code

pnpm-lock.yaml[R36877-36878]
+    peerDependencies:
+      chai: 5.2.1

Evidence
The only tracker source import of Chai is the newly added spec, while the workspace explicitly marks
spec files as dev files. A sibling component with the same style of Chai spec import records Chai
under devDependencies, but the tracker lockfile now declares Chai as a peer and auto-installs it
under dependencies.
scopes/component/tracker/determine-main-file.spec.ts[1-5]
workspace.jsonc[737-742]
scopes/component/component-url/component-url.spec.ts[1-4]
pnpm-lock.yaml[18612-18624]
pnpm-lock.yaml[19818-19840]
pnpm-lock.yaml[36872-36878]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tracker unit spec imports Chai, but the generated package metadata declares `chai@5.2.1` as an exact peer dependency of `@teambit/tracker`. This leaks a test-only library into the published runtime contract and forces consumers to resolve it.
## Issue Context
The workspace declares `**/*.spec.ts` as dev files. Other components with Chai imports in spec files record Chai under `devDependencies`, while the tracker lockfile entry now exposes it as a peer and auto-installs it as a regular importer dependency.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[1-5]
- workspace.jsonc[737-742]
- pnpm-lock.yaml[19818-19840]
- pnpm-lock.yaml[36872-36878]
Update the tracker component dependency metadata/configuration so Chai is detected as a dev dependency for the spec, then regenerate the lockfile and verify the tracker package no longer declares a Chai peer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Tip of the day

💡 Did you know, you can reply 'qodo' on any finding to push back, ask questions, or dig deeper

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 4ebf563 ⚖️ Balanced

Results up to commit b796a27

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

1. Error details no longer tested 🐞 Bug ⚙ Maintainability ⭐ New

Description

The replacement no-main-file unit test accepts any MissingMainFile instance, so regressions that
report the wrong component ID, expected main-file pattern, file list, or user-facing message now
pass. The removed e2e assertion constructed the expected component-specific error, while production
still builds those details separately from the exception type.

Code

scopes/component/tracker/determine-main-file.spec.ts[22]
+      expect(() => determineMainFile(addedComponent, null)).to.throw(MissingMainFile);

Evidence
The production function independently assembles and passes three error arguments, and
MissingMainFile stores them and formats the displayed message. A class-only assertion cannot
detect incorrect values in any of those paths.
scopes/component/tracker/determine-main-file.ts[38-43]
components/legacy/bit-map/exceptions/missing-main-file.ts[10-18]
scopes/component/tracker/determine-main-file.spec.ts[18-23]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The replacement unit test verifies only the `MissingMainFile` class, losing coverage of the component-specific error details that the removed e2e test checked.

## Issue Context
`determineMainFile()` supplies the component ID, expected main-file pattern, and candidate files to `MissingMainFile`; these values determine its user-facing message.

## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[18-23]
- scopes/component/tracker/determine-main-file.ts[38-43]
- components/legacy/bit-map/exceptions/missing-main-file.ts[10-18]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Depth validation branch untested 🐞 Bug ⚙ Maintainability

Description

The renamed test claims to cover any non-positive-integer depth but still passes only 0, so it
exercises the < 1 branch while the distinct Number.isInteger() rejection for abc and 1.5 now
has no test. A regression that accepts nonnumeric or fractional depths would therefore pass this
suite despite violating the command contract.

Code

e2e/commands/import.e2e.ts[R483-486]

+      it('should error when --dependencies-depth is not a positive integer', () => {
    const output = helper.general.runWithTryCatch(
      `bit import ${helper.scopes.remote}/comp1 --dependencies --dependencies-depth 0`
    );

Evidence

The remaining test invokes only depth 0, whereas command parsing has a separate
Number.isInteger() condition needed to reject both NaN from abc and fractional values such as
1.5; the PR deleted the only shown cases exercising those inputs.

e2e/commands/import.e2e.ts[483-488]
scopes/scope/importer/import.cmd.ts[324-331]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The consolidated dependencies-depth test only supplies zero, leaving the non-integer validation path uncovered while claiming all invalid positive-integer inputs are tested.
## Issue Context
`ImportCmd.report()` converts the option with `Number()` and rejects it using two distinct checks: `!Number.isInteger(...)` and `< 1`. Keep zero coverage and add at least one non-integer input (preferably both nonnumeric and fractional cases), either here or in a focused unit spec for the parser.
## Fix Focus Areas
- e2e/commands/import.e2e.ts[483-488]
- scopes/scope/importer/import.cmd.ts[324-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Test library becomes runtime peer 🐞 Bug ⚙ Maintainability

Description

Adding the Chai-only spec causes @teambit/tracker to declare an exact chai@5.2.1 peer, so
downstream runtime consumers must resolve a test framework that tracker production code never uses.
The repository classifies **/*.spec.ts as dev files, and comparable component specs keep Chai in
devDependencies, so this generated peer is an incorrect dependency classification.

Code

pnpm-lock.yaml[R36877-36878]
+    peerDependencies:
+      chai: 5.2.1

Evidence
The only tracker source import of Chai is the newly added spec, while the workspace explicitly marks
spec files as dev files. A sibling component with the same style of Chai spec import records Chai
under devDependencies, but the tracker lockfile now declares Chai as a peer and auto-installs it
under dependencies.
scopes/component/tracker/determine-main-file.spec.ts[1-5]
workspace.jsonc[737-742]
scopes/component/component-url/component-url.spec.ts[1-4]
pnpm-lock.yaml[18612-18624]
pnpm-lock.yaml[19818-19840]
pnpm-lock.yaml[36872-36878]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tracker unit spec imports Chai, but the generated package metadata declares `chai@5.2.1` as an exact peer dependency of `@teambit/tracker`. This leaks a test-only library into the published runtime contract and forces consumers to resolve it.
## Issue Context
The workspace declares `**/*.spec.ts` as dev files. Other components with Chai imports in spec files record Chai under `devDependencies`, while the tracker lockfile entry now exposes it as a peer and auto-installs it as a regular importer dependency.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[1-5]
- workspace.jsonc[737-742]
- pnpm-lock.yaml[19818-19840]
- pnpm-lock.yaml[36872-36878]
Update the tracker component dependency metadata/configuration so Chai is detected as a dev dependency for the spec, then regenerate the lockfile and verify the tracker package no longer declares a Chai peer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit ad4258a

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Depth validation branch untested 🐞 Bug ⚙ Maintainability

Description

The renamed test claims to cover any non-positive-integer depth but still passes only 0, so it
exercises the < 1 branch while the distinct Number.isInteger() rejection for abc and 1.5 now
has no test. A regression that accepts nonnumeric or fractional depths would therefore pass this
suite despite violating the command contract.

Code

e2e/commands/import.e2e.ts[R483-486]

+      it('should error when --dependencies-depth is not a positive integer', () => {
      const output = helper.general.runWithTryCatch(
        `bit import ${helper.scopes.remote}/comp1 --dependencies --dependencies-depth 0`
      );

Evidence

The remaining test invokes only depth 0, whereas command parsing has a separate
Number.isInteger() condition needed to reject both NaN from abc and fractional values such as
1.5; the PR deleted the only shown cases exercising those inputs.

e2e/commands/import.e2e.ts[483-488]
scopes/scope/importer/import.cmd.ts[324-331]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The consolidated dependencies-depth test only supplies zero, leaving the non-integer validation path uncovered while claiming all invalid positive-integer inputs are tested.
## Issue Context
`ImportCmd.report()` converts the option with `Number()` and rejects it using two distinct checks: `!Number.isInteger(...)` and `< 1`. Keep zero coverage and add at least one non-integer input (preferably both nonnumeric and fractional cases), either here or in a focused unit spec for the parser.
## Fix Focus Areas
- e2e/commands/import.e2e.ts[483-488]
- scopes/scope/importer/import.cmd.ts[324-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Test library becomes runtime peer 🐞 Bug ⚙ Maintainability

Description

Adding the Chai-only spec causes @teambit/tracker to declare an exact chai@5.2.1 peer, so
downstream runtime consumers must resolve a test framework that tracker production code never uses.
The repository classifies **/*.spec.ts as dev files, and comparable component specs keep Chai in
devDependencies, so this generated peer is an incorrect dependency classification.

Code

pnpm-lock.yaml[R36877-36878]
+    peerDependencies:
+      chai: 5.2.1

Evidence
The only tracker source import of Chai is the newly added spec, while the workspace explicitly marks
spec files as dev files. A sibling component with the same style of Chai spec import records Chai
under devDependencies, but the tracker lockfile now declares Chai as a peer and auto-installs it
under dependencies.
scopes/component/tracker/determine-main-file.spec.ts[1-5]
workspace.jsonc[737-742]
scopes/component/component-url/component-url.spec.ts[1-4]
pnpm-lock.yaml[18612-18624]
pnpm-lock.yaml[19818-19840]
pnpm-lock.yaml[36872-36878]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tracker unit spec imports Chai, but the generated package metadata declares `chai@5.2.1` as an exact peer dependency of `@teambit/tracker`. This leaks a test-only library into the published runtime contract and forces consumers to resolve it.
## Issue Context
The workspace declares `**/*.spec.ts` as dev files. Other components with Chai imports in spec files record Chai under `devDependencies`, while the tracker lockfile entry now exposes it as a peer and auto-installs it as a regular importer dependency.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[1-5]
- workspace.jsonc[737-742]
- pnpm-lock.yaml[19818-19840]
- pnpm-lock.yaml[36872-36878]
Update the tracker component dependency metadata/configuration so Chai is detected as a dev dependency for the spec, then regenerate the lockfile and verify the tracker package no longer declares a Chai peer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit ad34d94

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Depth validation branch untested 🐞 Bug ⚙ Maintainability ⭐ New

Description

The renamed test claims to cover any non-positive-integer depth but still passes only 0, so it
exercises the < 1 branch while the distinct Number.isInteger() rejection for abc and 1.5 now
has no test. A regression that accepts nonnumeric or fractional depths would therefore pass this
suite despite violating the command contract.

Code

e2e/commands/import.e2e.ts[R483-486]

+      it('should error when --dependencies-depth is not a positive integer', () => {
        const output = helper.general.runWithTryCatch(
          `bit import ${helper.scopes.remote}/comp1 --dependencies --dependencies-depth 0`
        );

Evidence

The remaining test invokes only depth 0, whereas command parsing has a separate
Number.isInteger() condition needed to reject both NaN from abc and fractional values such as
1.5; the PR deleted the only shown cases exercising those inputs.

e2e/commands/import.e2e.ts[483-488]
scopes/scope/importer/import.cmd.ts[324-331]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The consolidated dependencies-depth test only supplies zero, leaving the non-integer validation path uncovered while claiming all invalid positive-integer inputs are tested.

## Issue Context
`ImportCmd.report()` converts the option with `Number()` and rejects it using two distinct checks: `!Number.isInteger(...)` and `< 1`. Keep zero coverage and add at least one non-integer input (preferably both nonnumeric and fractional cases), either here or in a focused unit spec for the parser.

## Fix Focus Areas
- e2e/commands/import.e2e.ts[483-488]
- scopes/scope/importer/import.cmd.ts[324-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Test library becomes runtime peer 🐞 Bug ⚙ Maintainability

Description

Adding the Chai-only spec causes @teambit/tracker to declare an exact chai@5.2.1 peer, so
downstream runtime consumers must resolve a test framework that tracker production code never uses.
The repository classifies **/*.spec.ts as dev files, and comparable component specs keep Chai in
devDependencies, so this generated peer is an incorrect dependency classification.

Code

pnpm-lock.yaml[R36877-36878]
+    peerDependencies:
+      chai: 5.2.1

Evidence
The only tracker source import of Chai is the newly added spec, while the workspace explicitly marks
spec files as dev files. A sibling component with the same style of Chai spec import records Chai
under devDependencies, but the tracker lockfile now declares Chai as a peer and auto-installs it
under dependencies.
scopes/component/tracker/determine-main-file.spec.ts[1-5]
workspace.jsonc[737-742]
scopes/component/component-url/component-url.spec.ts[1-4]
pnpm-lock.yaml[18612-18624]
pnpm-lock.yaml[19818-19840]
pnpm-lock.yaml[36872-36878]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tracker unit spec imports Chai, but the generated package metadata declares `chai@5.2.1` as an exact peer dependency of `@teambit/tracker`. This leaks a test-only library into the published runtime contract and forces consumers to resolve it.
## Issue Context
The workspace declares `**/*.spec.ts` as dev files. Other components with Chai imports in spec files record Chai under `devDependencies`, while the tracker lockfile entry now exposes it as a peer and auto-installs it as a regular importer dependency.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[1-5]
- workspace.jsonc[737-742]
- pnpm-lock.yaml[19818-19840]
- pnpm-lock.yaml[36872-36878]
Update the tracker component dependency metadata/configuration so Chai is detected as a dev dependency for the spec, then regenerate the lockfile and verify the tracker package no longer declares a Chai peer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit aa5919c

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Test library becomes runtime peer 🐞 Bug ⚙ Maintainability

Description

Adding the Chai-only spec causes @teambit/tracker to declare an exact chai@5.2.1 peer, so
downstream runtime consumers must resolve a test framework that tracker production code never uses.
The repository classifies **/*.spec.ts as dev files, and comparable component specs keep Chai in
devDependencies, so this generated peer is an incorrect dependency classification.

Code

pnpm-lock.yaml[R36877-36878]
+    peerDependencies:
+      chai: 5.2.1

Evidence
The only tracker source import of Chai is the newly added spec, while the workspace explicitly marks
spec files as dev files. A sibling component with the same style of Chai spec import records Chai
under devDependencies, but the tracker lockfile now declares Chai as a peer and auto-installs it
under dependencies.
scopes/component/tracker/determine-main-file.spec.ts[1-5]
workspace.jsonc[737-742]
scopes/component/component-url/component-url.spec.ts[1-4]
pnpm-lock.yaml[18612-18624]
pnpm-lock.yaml[19818-19840]
pnpm-lock.yaml[36872-36878]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tracker unit spec imports Chai, but the generated package metadata declares `chai@5.2.1` as an exact peer dependency of `@teambit/tracker`. This leaks a test-only library into the published runtime contract and forces consumers to resolve it.
## Issue Context
The workspace declares `**/*.spec.ts` as dev files. Other components with Chai imports in spec files record Chai under `devDependencies`, while the tracker lockfile entry now exposes it as a peer and auto-installs it as a regular importer dependency.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[1-5]
- workspace.jsonc[737-742]
- pnpm-lock.yaml[19818-19840]
- pnpm-lock.yaml[36872-36878]
Update the tracker component dependency metadata/configuration so Chai is detected as a dev dependency for the spec, then regenerate the lockfile and verify the tracker package no longer declares a Chai peer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 2a1b66d

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Test library becomes runtime peer 🐞 Bug ⚙ Maintainability

Description

Adding the Chai-only spec causes @teambit/tracker to declare an exact chai@5.2.1 peer, so
downstream runtime consumers must resolve a test framework that tracker production code never uses.
The repository classifies **/*.spec.ts as dev files, and comparable component specs keep Chai in
devDependencies, so this generated peer is an incorrect dependency classification.

Code

pnpm-lock.yaml[R36877-36878]
+    peerDependencies:
+      chai: 5.2.1

Evidence
The only tracker source import of Chai is the newly added spec, while the workspace explicitly marks
spec files as dev files. A sibling component with the same style of Chai spec import records Chai
under devDependencies, but the tracker lockfile now declares Chai as a peer and auto-installs it
under dependencies.
scopes/component/tracker/determine-main-file.spec.ts[1-5]
workspace.jsonc[737-742]
scopes/component/component-url/component-url.spec.ts[1-4]
pnpm-lock.yaml[18612-18624]
pnpm-lock.yaml[19818-19840]
pnpm-lock.yaml[36872-36878]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tracker unit spec imports Chai, but the generated package metadata declares `chai@5.2.1` as an exact peer dependency of `@teambit/tracker`. This leaks a test-only library into the published runtime contract and forces consumers to resolve it.
## Issue Context
The workspace declares `**/*.spec.ts` as dev files. Other components with Chai imports in spec files record Chai under `devDependencies`, while the tracker lockfile entry now exposes it as a peer and auto-installs it as a regular importer dependency.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[1-5]
- workspace.jsonc[737-742]
- pnpm-lock.yaml[19818-19840]
- pnpm-lock.yaml[36872-36878]
Update the tracker component dependency metadata/configuration so Chai is detected as a dev dependency for the spec, then regenerate the lockfile and verify the tracker package no longer declares a Chai peer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 3e5d887

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Test library becomes runtime peer 🐞 Bug ⚙ Maintainability

Description

Adding the Chai-only spec causes @teambit/tracker to declare an exact chai@5.2.1 peer, so
downstream runtime consumers must resolve a test framework that tracker production code never uses.
The repository classifies **/*.spec.ts as dev files, and comparable component specs keep Chai in
devDependencies, so this generated peer is an incorrect dependency classification.

Code

pnpm-lock.yaml[R36877-36878]
+    peerDependencies:
+      chai: 5.2.1

Evidence
The only tracker source import of Chai is the newly added spec, while the workspace explicitly marks
spec files as dev files. A sibling component with the same style of Chai spec import records Chai
under devDependencies, but the tracker lockfile now declares Chai as a peer and auto-installs it
under dependencies.
scopes/component/tracker/determine-main-file.spec.ts[1-5]
workspace.jsonc[737-742]
scopes/component/component-url/component-url.spec.ts[1-4]
pnpm-lock.yaml[18612-18624]
pnpm-lock.yaml[19818-19840]
pnpm-lock.yaml[36872-36878]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tracker unit spec imports Chai, but the generated package metadata declares `chai@5.2.1` as an exact peer dependency of `@teambit/tracker`. This leaks a test-only library into the published runtime contract and forces consumers to resolve it.
## Issue Context
The workspace declares `**/*.spec.ts` as dev files. Other components with Chai imports in spec files record Chai under `devDependencies`, while the tracker lockfile entry now exposes it as a peer and auto-installs it as a regular importer dependency.
## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[1-5]
- workspace.jsonc[737-742]
- pnpm-lock.yaml[19818-19840]
- pnpm-lock.yaml[36872-36878]
Update the tracker component dependency metadata/configuration so Chai is detected as a dev dependency for the spec, then regenerate the lockfile and verify the tracker package no longer declares a Chai peer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit c63cc61

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Test library becomes runtime peer 🐞 Bug ⚙ Maintainability

Description

Adding the Chai-only spec causes @teambit/tracker to declare an exact chai@5.2.1 peer, so
downstream runtime consumers must resolve a test framework that tracker production code never uses.
The repository classifies **/*.spec.ts as dev files, and comparable component specs keep Chai in
devDependencies, so this generated peer is an incorrect dependency classification.

Code

pnpm-lock.yaml[R36877-36878]
+    peerDependencies:
+      chai: 5.2.1

Evidence
The only tracker source import of Chai is the newly added spec, while the workspace explicitly marks
spec files as dev files. A sibling component with the same style of Chai spec import records Chai
under devDependencies, but the tracker lockfile now declares Chai as a peer and auto-installs it
under dependencies.
scopes/component/tracker/determine-main-file.spec.ts[1-5]
workspace.jsonc[737-742]
scopes/component/component-url/component-url.spec.ts[1-4]
pnpm-lock.yaml[18612-18624]
pnpm-lock.yaml[19818-19840]
pnpm-lock.yaml[36872-36878]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tracker unit spec imports Chai, but the generated package metadata declares `chai@5.2.1` as an exact peer dependency of `@teambit/tracker`. This leaks a test-only library into the published runtime contract and forces consumers to resolve it.

## Issue Context
The workspace declares `**/*.spec.ts` as dev files. Other components with Chai imports in spec files record Chai under `devDependencies`, while the tracker lockfile entry now exposes it as a peer and auto-installs it as a regular importer dependency.

## Fix Focus Areas
- scopes/component/tracker/determine-main-file.spec.ts[1-5]
- workspace.jsonc[737-742]
- pnpm-lock.yaml[19818-19840]
- pnpm-lock.yaml[36872-36878]

Update the tracker component dependency metadata/configuration so Chai is detected as a dev dependency for the spec, then regenerate the lockfile and verify the tracker package no longer declares a Chai peer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-free-for-open-source-projects · 2026-08-20T21:49:21Z

Code review by qodo was updated up to the latest commit 23f127b

qodo-free-for-open-source-projects · 2026-08-20T22:21:14Z

Code review by qodo was updated up to the latest commit c9b3b48

qodo-free-for-open-source-projects · 2026-08-21T02:32:21Z

Code review by qodo was updated up to the latest commit d064888

qodo-free-for-open-source-projects · 2026-08-21T02:39:01Z

Code review by qodo was updated up to the latest commit 8d4db88

qodo-free-for-open-source-projects · 2026-08-21T02:48:53Z

Code review by qodo was updated up to the latest commit d15dbd2

qodo-free-for-open-source-projects · 2026-08-21T03:51:31Z

Code review by qodo was updated up to the latest commit ec76886

qodo-free-for-open-source-projects · 2026-08-21T04:51:18Z

Code review by qodo was updated up to the latest commit 0b6f4b3

qodo-free-for-open-source-projects · 2026-08-21T05:48:19Z

Code review by qodo was updated up to the latest commit 42014fb

qodo-free-for-open-source-projects · 2026-08-25T19:54:19Z

Code review by qodo was updated up to the latest commit 3e5d887

qodo-free-for-open-source-projects · 2026-08-25T20:40:55Z

Code review by qodo was updated up to the latest commit 2a1b66d

qodo-free-for-open-source-projects · 2026-08-25T20:52:26Z

Code review by qodo was updated up to the latest commit aa5919c

…n e2e

qodo-free-for-open-source-projects · 2026-08-26T12:14:37Z

+      it('should error when --dependencies-depth is not a positive integer', () => {
        const output = helper.general.runWithTryCatch(
          `bit import ${helper.scopes.remote}/comp1 --dependencies --dependencies-depth 0`
        );


1. Depth validation branch untested 🐞 Bug ⚙ Maintainability

The renamed test claims to cover any non-positive-integer depth but still passes only 0, so it exercises the < 1 branch while the distinct Number.isInteger() rejection for abc and 1.5 now has no test. A regression that accepts nonnumeric or fractional depths would therefore pass this suite despite violating the command contract.

Agent Prompt

## Issue description The consolidated dependencies-depth test only supplies zero, leaving the non-integer validation path uncovered while claiming all invalid positive-integer inputs are tested. ## Issue Context `ImportCmd.report()` converts the option with `Number()` and rejects it using two distinct checks: `!Number.isInteger(...)` and `< 1`. Keep zero coverage and add at least one non-integer input (preferably both nonnumeric and fractional cases), either here or in a focused unit spec for the parser. ## Fix Focus Areas - e2e/commands/import.e2e.ts[483-488] - scopes/scope/importer/import.cmd.ts[324-331]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-free-for-open-source-projects · 2026-08-26T12:14:39Z

Code review by qodo was updated up to the latest commit ad34d94

qodo-free-for-open-source-projects · 2026-08-26T13:26:49Z

Code review by qodo was updated up to the latest commit ad4258a

…es e2e

… fixtures

qodo-free-for-open-source-projects · 2026-08-27T13:22:53Z

+      const addedComponent = createAddedComponent({
+        files: [{ relativePath: 'bar/foo1.js' }, { relativePath: 'bar/foo2.js' }],
+      });
+      expect(() => determineMainFile(addedComponent, null)).to.throw(MissingMainFile);


1. Error details no longer tested 🐞 Bug ⚙ Maintainability

The replacement no-main-file unit test accepts any MissingMainFile instance, so regressions that report the wrong component ID, expected main-file pattern, file list, or user-facing message now pass. The removed e2e assertion constructed the expected component-specific error, while production still builds those details separately from the exception type.

Agent Prompt

## Issue description The replacement unit test verifies only the `MissingMainFile` class, losing coverage of the component-specific error details that the removed e2e test checked. ## Issue Context `determineMainFile()` supplies the component ID, expected main-file pattern, and candidate files to `MissingMainFile`; these values determine its user-facing message. ## Fix Focus Areas - scopes/component/tracker/determine-main-file.spec.ts[18-23] - scopes/component/tracker/determine-main-file.ts[38-43] - components/legacy/bit-map/exceptions/missing-main-file.ts[10-18]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-free-for-open-source-projects · 2026-08-27T13:22:55Z

Code review by qodo was updated up to the latest commit b796a27

# Conflicts: # pnpm-lock.yaml

qodo-free-for-open-source-projects · 2026-08-28T12:35:25Z

Code review by qodo was updated up to the latest commit 4ebf563

test(e2e): remove redundant add/config e2e tests, add determine-main-…

86ddb05

…file unit spec

qodo-free-for-open-source-projects Bot reviewed Aug 20, 2026

View reviewed changes

Comment thread scopes/component/tracker/determine-main-file.spec.ts

test(e2e): trim diff e2e tests

23f127b

test(e2e): fix mislabeled describe title in export e2e

c9b3b48

test(e2e): trim import e2e tests

d064888

qodo-free-for-open-source-projects Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread scopes/component/tracker/determine-main-file.spec.ts

test(e2e): trim init e2e tests

8d4db88

qodo-free-for-open-source-projects Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread scopes/component/tracker/determine-main-file.spec.ts

test(e2e): trim list e2e tests

d15dbd2

qodo-free-for-open-source-projects Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread e2e/commands/config.e2e.ts

qodo-free-for-open-source-projects Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread e2e/commands/import.e2e.ts

qodo-free-for-open-source-projects Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread e2e/commands/init.e2e.ts

qodo-free-for-open-source-projects Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread e2e/commands/init.e2e.ts

test(e2e): trim pattern e2e tests

ec76886

qodo-free-for-open-source-projects Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread e2e/commands/import.e2e.ts

Comment thread e2e/commands/add.e2e.ts

qodo-free-for-open-source-projects Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread e2e/commands/pattern.e2e.ts

test(e2e): fix mislabeled lane describe titles in remove e2e

0b6f4b3

qodo-free-for-open-source-projects Bot reviewed Aug 21, 2026

View reviewed changes

Comment thread e2e/commands/pattern.e2e.ts

test(e2e): trim search e2e tests

42014fb

test(e2e): trim tag e2e tests

7b57c23

test(e2e): trim custom-env-operations e2e tests, fix no-op assertion

2a1b66d

test(e2e): remove dead skip and duplicate after hook in custom-env e2e

aa5919c

test(e2e): remove simple scenario subsumed by complex in deduplicatio…

ad34d94

…n e2e

qodo-free-for-open-source-projects Bot reviewed Aug 26, 2026

View reviewed changes

test(e2e): fix stale config re-read in dependencies-cmd e2e

ad4258a

davidfirst added 8 commits August 26, 2026 11:40

test(e2e): remove deprecated-yarn dead skip in never-built-dependenci…

b6e33a1

…es e2e

test(e2e): merge capsule package.json pair in optional-dependencies e2e

b30529f

test(e2e): trim dependency-resolver e2e tests

04b5fd5

test(e2e): remove deprecated-yarn dead skips in deps-in-capsules e2e

5d896dd

test(e2e): dedupe flag-independent assertions in eject-harmony e2e

86cc51e

test(e2e): remove 5-year-skipped resume-export suites and their stale…

6634c31

… fixtures

test(e2e): remove placeholder skip in extensions-config-diff e2e

5cc109e

test(e2e): trim extensions-config e2e tests

b796a27

qodo-free-for-open-source-projects Bot reviewed Aug 27, 2026

View reviewed changes

davidfirst added 8 commits August 27, 2026 09:53

Merge remote-tracking branch 'origin/master' into e2e-cleanup

25e3a81

# Conflicts: # pnpm-lock.yaml

chore: update pnpm-lock after master merge

b014c4f

test(e2e): trim import-harmony e2e tests

13e9dc4

test(e2e): fix copy-pasted test name in imported-component-deps e2e

377240c

test(e2e): remove deprecated yarn describe in install-and-compile e2e

a995654

test(e2e): remove dead yarn and obsolete skipped tests in install e2e

05f8d3c

test(e2e): remove pattern-variation describe in internalize e2e

72bcd9f

test(e2e): drop duplicate jest runs in jest e2e

4ebf563

luvkapur mentioned this pull request Aug 28, 2026

refactor(react, docs): derive component props from the API schema, drop react-docgen #10621

Open

Uh oh!

Conversation

davidfirst commented Aug 20, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 20, 2026

PR Summary by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 20, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 20, 2026

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 21, 2026

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 21, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 21, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 21, 2026

Uh oh!

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 21, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 21, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 25, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 25, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 25, 2026

Uh oh!

qodo-free-for-open-source-projects Bot Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 26, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 26, 2026

Uh oh!

qodo-free-for-open-source-projects Bot Aug 27, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 27, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

qodo-free-for-open-source-projects Bot commented Aug 20, 2026 •

edited

Loading