Bit 2.0.26: Multiple Regressions in Build Pipeline (TypeScript, Rspack, Vitest, CLI and Diagnostics)

[rvnlord]

Environment

• Windows 10/11
• Bit: 2.0.26
• @bitdev/react.react-env: 6.0.25
• @bitdev/general.envs.bit-env: 6.0.2

Relevant packages:

@teambit/builder: ^1.0.1078
@teambit/defender.prettier-formatter: ^1.0.24
@teambit/harmony: ^0.4.12
@teambit/oxc.linter.oxlint-linter: ^2.0.6
@teambit/preview.react-preview: ^1.1.12
@teambit/react.mounter: ^1.1.8
@teambit/rspack.dev-services.preview.react-preview: ^1.0.14
@teambit/rspack.modules.rspack-config-mutator: ^1.0.23
@teambit/typescript.typescript-compiler: ^5.0.0
@teambit/vite.vitest-tester: ^0.4.16

While upgrading to Bit 2.0.26, I encountered multiple regressions affecting bit build, bit lint, Vitest integration, Rspack and diagnostics.

---

1. Regression: bit build emits no JS files if include is inherited via extends

Root Cause

TypescriptCompiler.computeTsConfig() uses get-tsconfig to resolve extends chains.

Example:

// projects/commonlib/envs/my-react-env/config/tsconfig.json
{
    "extends": "@bitdev/react.react-env/config/tsconfig.json"
}

The base config contains:

{
    "include": ["**/*", "**/*.json"]
}

get-tsconfig deep-merges the configs and re-roots inherited include paths relative to the child config location.

As a result, capsule tsconfig.json files contain:

{
    "include": [
        "../../../../@bitdev/react.react-env/config/**/*",
        "../../../../@bitdev/react.react-env/config/**/*.json"
    ]
}

This causes TypeScript to compile only env configuration files instead of component source files, resulting in zero emitted .js output during bit build.

Workaround

Explicitly define include and exclude in the env's own config/tsconfig.json instead of inheriting them.

---

2. Regression: ESM package builds fail for local imports without .js extensions

Given:

"teambit.pkg/pkg": {
    "packageJson": {
        "exported": true,
        "type": "module",
        "sideEffects": true
    }
}

bit build fails with:

Module not found: Can't resolve './status-code'
Did you mean './status-code.js'?

Generated output:

import { StatusCodeType } from "./status-code";

Expected output:

import { StatusCodeType } from "./status-code.js";

This appears to be an ESM compatibility regression. The generated JS is incompatible with "type": "module" packages unless all relative imports are rewritten to include extensions.

---

3. Rspack does not support node: specifiers during bit build

Dependencies using modern Node specifiers:

import "node:stream";
import "node:string_decoder";

produce:

Reading from "node:stream" is not handled by plugins (Unhandled scheme).
Rspack supports "data:" and "file:" URIs by default.

Notably:

• resolve.alias does not work.
• resolve.fallback does not work.
• NormalModuleReplacementPlugin is either never reached or incompatible with Bit's compiler wrapper.
• The only successful workaround is externalizing the modules:

externals: [
    ({ request }, callback) => {
        if (request === "node:stream") {
            return callback(
                undefined,
                "var " + JSON.stringify(
                    esmRequire.resolve("stream-browserify")
                )
            );
        }

        if (request === "node:string_decoder") {
            return callback(
                undefined,
                "var " + JSON.stringify(
                    esmRequire.resolve("string_decoder/")
                )
            );
        }

        callback();
    }
]

Surprisingly, this bypasses the URI scheme validation and allows bit build to complete.

This suggests externals are processed before node: URI validation, while aliases/fallbacks/plugins are not.

---

4. bit install rejects valid Rspack/browser polyfill packages

Examples:

bit install stream-browserify string_decoder events

the package name "string_decoder" is invalid.

bit install stream-browserify events

the package name "events" is invalid.

Both events and string_decoder are valid npm package names and install correctly with pnpm/npm.

---

5. ExtractSchema logs non-descriptive errors

During bit build:

teambit.typescript/typescript, Error in request: [object Object]

These messages may appear dozens of times and are followed by:

[Schema: ExtractSchema] Completed successfully

This makes diagnosing actual schema extraction issues extremely difficult.

At minimum, errors should be serialized properly:

logger.error(error);

or:

logger.error(JSON.stringify(error, null, 2));

instead of:

logger.error(`Error in request: ${error}`);

---

6. Vitest integration still reports 0% coverage and misses nested tests

Despite recent fixes, bit build/bit test still exhibit the following behavior:

• Coverage remains 0%.
• Nested tests are not discovered.
• Running Vitest directly with the same configuration produces correct results.
• Additionally, the same tests that run during bit build are significantly slower (5x) than the same set running under bit test/vitest test with the same options. It is especially noticable with pool: "threads".

This suggests the issue remains somewhere in Bit's Vitest integration layer rather than in Vitest itself.

---

7. bit lint reports success while oxlint reports warnings

Using the same configuration:

bit lint

reports no issues, while:

oxlint

correctly reports warnings.

This makes bit lint unreliable as a source of truth for CI validation.

---

8. bit build ignores Vite build configuration options

bit build reports loading the expected vite.config file, but some build options are not respected.

Example configuration:

build: {
    chunkSizeWarningLimit: 10000,
    reportCompressedSize: false,
}

Despite this, bit build still outputs:

(!) Some chunks are larger than 500 kB after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit

and continues to report compressed (gzip) sizes.

This suggests that Bit is merging/overwriting build options internally. The same vite.config is being fully respected during bit run.

---

9. Incorrect Rspack/esbuild warnings about import.meta with CJS output

bit build reports warnings that import.meta is unavailable because the output format is supposedly cjs:

▲ [WARNING] "import.meta" is not available with the "cjs" output format and will be empty [empty-import-meta]

    .../dist/console-test.js:16:12:
      16 │     let t = import.meta.url;
         ╵             ~~~~~~~~~~~

  You need to set the output format to "esm" for "import.meta" to work correctly.

and:

▲ [WARNING] "import.meta" is not available with the "cjs" output format and will be empty [empty-import-meta]

    .../dist/console-test.js:20:41:
      20 │     const require = module.createRequire(import.meta.url);
         ╵                                          ~~~~~~~~~~~

But, the environment/package configuration already sets the output format correctly (preserve/bundler), and this has been verified to work outside of Bit as well as with bit run.

This appears to be another case where bit build internally invokes a bundler step with configuration that differs from the user-provided configuration, or where intermediate build artifacts are incorrectly passed through a CJS-targeted transform.

---

Summary

Individually, each issue has a workaround. Collectively, however, they significantly affect the reliability of Bit's build pipeline:

• TypeScript capsules silently emit no JS.
• ESM packages fail to bundle.
• Modern node: specifiers are unsupported.
• CLI rejects valid package names.
• Diagnostics are improperly stringified.
• Vitest coverage remains broken.
• bit lint disagrees with oxlint.
• Configuration options are ignored.
• bit build warnings and errors are misleading as they often don't adhere to actual, otherwise working, configurations.

[GiladShoham]

Thanks for reporting these issues.
We will check them one by one and fix everything.
We did some major upgrades recently like start moving things to typescript 7 which affects many other things down the road.
Can you please let us know which versions worked fine for you?
Thanks