Duplicate esbuild binaries shipped in the VS Code extension

[fbricon]

Before submitting your bug report

• I believe this is a bug. I'll try to join the Continue Discord for questions
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS: Mac OS
- Continue version: 0.9.261
- IDE version: VS Code 1.96.4

Description

The Continue vsix ships 2 esbuild 0.17.19 binaries in out/node_modules, wasting an extra ~9MB of bandwidth/space.

To reproduce

No response

Log output

[fbricon]

it seems the esbuild/bin/esbuild binary could be removed, as esbuild will delegate to the specific @esbuild/<target>/bin/esbuild version.

[Patrick-Erichsen]

it seems the esbuild/bin/esbuild binary could be removed, as esbuild will delegate to the specific @esbuild//bin/esbuild version.

That seems correct. Added a good-first-issue label to this if anyone is interested! Otherwise will keep it on our radar.

[Riddhimaan-Senapati]

@Patrick-Erichsen I would like to contribute.

[joffeoja]

Should the esbuild binary be packaged into the vsix package at all? esbuild is configured as 'external' in esbuild.js with the purpose of excluding the package but since esbuild is configured as both 'devDependency' AND 'dependency' in package.json it doesn't get excluded. That's my take on this anyway

Documentation says to install esbuild using npm install --save-exact --save-dev esbuild , i.e. put it into devDependencies

[Patrick-Erichsen]

The only reason we bundle esbuild is for users that define a custom config.ts - we are moving away from this pattern and will eventually remove esbuild from the bundle entirely, so this this won't be an issue in the near to mid-term.

@Riddhimaan-Senapati - if you'd still like to contribute here are some good first issues: good-first-issue Suggested issue for new contributors

Feel free to follow up with me if anything catches your eye!

[joffeoja]

@Patrick-Erichsen: When you reverted back to the old esbuild 0.17.19 the vscode package again gets flagged by vulnerability scanners. Lots of warnings. This is what you see when using an off the shelf scanner commonly used in a corp environment:
evanw/esbuild#3802

[dabockster]

I played around with this a bit in the codebase, and it looks like the big culprits are how esbuild.js and package.js do architecture checking (found in ./extensions/vscode/scripts) during the build process. I got it to build but not launch - the debugger kept saying that sqlite module wasn't a win32 application. I also still saw this error after multiple AI-assisted refactors.

I also noticed that the build system itself feels like tangled christmas lights, given how all the code for both the VSCode and Intellij platforms are in the same repo. I'm gonna open a new issue to recommend those be broken up into two codebase (and two build systems.