Category X: jschardet pulled in by @codingame/monaco-vscode-api

[bobbai00]

What happened?

`jschardet` (npm) is LGPL-2.1, an ASF Category X license, and cannot ship in an Apache binary distribution. It is pulled in transitively by the direct dependency `@codingame/monaco-vscode-api` (declared in `frontend/package.json` as `"vscode": "npm:@codingame/monaco-vscode-api@8.0.4"`).

How to reproduce?

```
grep -A3 '^"vscode@npm' frontend/yarn.lock
```

Output shows `@codingame/monaco-vscode-api` declares `jschardet: "npm:3.1.3"` in its dependencies.

Version

1.1.0-incubating (Pre-release/Master)

Commit Hash (Optional)

ef66364

Proposed fix

Options:

• Replace `@codingame/monaco-vscode-api` with a narrower Monaco/VS Code API integration that does not ship charset detection.
• Use Yarn's `resolutions` or an import map to stub `jschardet` with a no-op compatible shim at build time.
• Remove the codepath that triggers `jschardet` loading and mark it as an explicitly unsupported VS Code feature in Texera's frontend.

Was this authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Claude Opus 4.7)

[bobbai00]

Proposed fix (By Claude Code)

Texera's own source never references jschardet (verified with grep -r jschardet frontend/src — no matches). The package is pulled in by @codingame/monaco-vscode-api and shipped to the production bundle only because webpack resolves the import from Monaco's code paths. Since those code paths are not exercised by Texera's editor integration, we can replace jschardet with a tiny no-op stub at bundle time and the package will stop appearing in the shipped bundle (and therefore in 3rdpartylicenses.txt and LICENSE-binary).

Suggested change

1. Add a stub at frontend/stubs/jschardet.js:

// jschardet is LGPL-2.1 and pulled in transitively by @codingame/monaco-vscode-api.
// Texera never calls it, so bundle-time aliasing replaces it with a no-op to keep
// LGPL code out of the shipped binary distribution.
module.exports = {
  detect: () => ({ encoding: "UTF-8", confidence: 1 }),
  detectAll: () => [{ encoding: "UTF-8", confidence: 1 }],
};

2. Extend the existing frontend/custom-webpack.config.js with a resolve.alias entry:

module.exports = {
  module: { /* ...existing rules... */ },
  resolve: {
    alias: {
      jschardet: require("path").resolve(__dirname, "stubs/jschardet.js"),
    },
  },
};

Verification

After the change:

1. yarn --cwd frontend run build completes.
2. grep -n jschardet frontend/dist/3rdpartylicenses.txt returns no matches (confirming it is no longer bundled).
3. The jschardet entry can be removed from LICENSE-binary's ASF Category X section once the content PR lands.

Alternatives considered

• yarn patch @codingame/monaco-vscode-api to delete jschardet imports upstream. More invasive; harder to maintain across upstream updates.
• Replace @codingame/monaco-vscode-api with plain monaco-editor. Would lose VS Code API extensions that Texera's editor depends on.
• Yarn resolutions → portal: stub package. Cleaner at install time, but finicky across CI environments.

The webpack-alias approach has the smallest diff, touches only files Texera already maintains, and keeps the LGPL code strictly out of the shipped artifact.

[bobbai00]

@aglinxinyuan I would like to have your inputs on this

[aglinxinyuan]

We don't need character encoding auto-detection from jschardet in the code editor, so I'm okay with removing it.
I don't like the proposed solution; it's too hacky. I made a PR for another solution.

[bobbai00]

Reopening: PR #4475 didn't actually remove jschardet.

Reproduced by:

  rm -rf frontend/node_modules

  yarn --cwd frontend install

  find frontend/node_modules -maxdepth 2 -name 'jschardet*' -type d
  grep -c 'jschardet' frontend/yarn.lock
  grep -B1 -A1 'jschardet' frontend/yarn.lock | head

[bobbai00]

@aglinxinyuan can you take another look?

[aglinxinyuan]

@aglinxinyuan can you take another look?

Working on the fix.

[aglinxinyuan]

Made another attempt to fix.