bobbai00 commented on issue #4461: URL: https://github.com/apache/texera/issues/4461#issuecomment-4301298928
Reopening: PR #4475 didn't actually remove `jschardet`. The `packageExtensions` rule keys on `@codingame/monaco-vscode-api@*`, but `package.json` aliases that package as `vscode`. Yarn resolves the aliased ident `vscode@npm:@codingame/monaco-vscode-api@...` in the lockfile and never applies the rule — it even emits `YN0069`: > `@codingame/monaco-vscode-api ➤ dependencies ➤ jschardet: This rule seems redundant when applied on the original package; the extension may have been applied upstream.` Verified after a clean `yarn install --refresh-lockfile` on upstream `main`: - `yarn.lock` still has `jschardet: "npm:3.1.3"` under the `vscode@npm:@codingame/[email protected]` block. - `frontend/node_modules/jschardet` is installed. - `frontend/dist/3rdpartylicenses.txt` still lists `jschardet` (LGPL-2.1+). A working fix likely needs one of: - `packageExtensions` keyed on the alias (`"vscode@npm:@codingame/monaco-vscode-api@*": { dependencies: { jschardet: null } }`), or - `resolutions: { "jschardet": "portal:./stubs/jschardet" }` with a local no-op stub, or - Webpack `resolve.alias.jschardet → stubs/jschardet.js` in `frontend/custom-webpack.config.js` (the suggestion in the earlier comment on this issue, which sidesteps the yarn-level complication entirely). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
