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

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.

@Patrick-Erichsen I would like to contribute.

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

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!

@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

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.

@Patrick-Erichsen: A quick reminder that as long as you include the "vulnerable" 0.17.19 version of esbuild in the VSCode extension package you are effectively barring a more security minded audience from using Continue. Luckily, the IntelliJ plugin does not have this problem anymore.

Thanks for the +1 here @joffeoja - followed up with the team about this. We're still planning to deprecate config.ts in the future, which would entirely remove esbuild as a dep, but in the short term we should definitely resolve this.