Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Was looking through startup perf at the request of devkit to see if there were things we could improve. The first commit is just misc cleanup and improvements - removes a few warnings that get reported in the extension host on startup.
In the second commit I switched to esbuild for bundling instead of webpack. I had noticed that the time to load extension code (~300ms) was much higher than our actual activation implementation (~30ms). Wanted to experiment to see if esbuild bundling reduced the output JS code size.
Unfortunately, both code size and time to load the code was essentially unchanged. However - there is an improvement in build times that I think makes this worth taking (and is expected, esbuild is way faster than webpack). In the linux leg in particular I'm seeing a roughly 3 min reduction in time


before:
after:
There are likely other things to improve there as well (e.g. removing eslint from the vsix build step).
At the same time, attempted to cleanup some of the scripts to make things a bit easier to understand.