TS - mangle private and protected props

[jrieken]

This PR is an attempt (and work in progress) to minify/mangle our shipped bundled by a TypeScript to TypeScript transformation. In essence it detects and renames all private and protected members of all classes and renamed them to shorter names. My initial testing shows a reduction of ~1.8MB. This replaces an earlier effort that would do a JS to JS in-place transformation.

The status is that it successfully rewrites the VS Code sources base and that the rewritten code successfully compiles. There are a few test failures because of evil casting where a private property-access is enforced, like so or so.

This needs hardening and more testing but already looks promising. Random todos

• get tests green
• review and cleanup
• put this into our build pipeline
• think about generating source maps and check if TS ingests source maps?

[jrieken]

FYI - This PR seems larger than it is because it changes the emit options for build/ to produce inline source maps

[mjbvz]

@jrieken Just pushed a change to try mangling webpacked extensions using a custom loader

[jrieken]

@alexr00 Thanks for the review!

[ahinkle]

This PR broke popular (with 100K+ active installs) UI customization plugins. Would there be any room to support them with available methods, or would you consider adding more flexible options to customize the UI?

iocave/customize-ui#156
iocave/monkey-patch#55

[isidorn]

@ahinkle thanks for reaching out. We already commented on the customize-ui extension here iocave/customize-ui#156 (comment)
More details can be found here microsoft/vscode-discussions#257

We would love to learn more about the missing customisations of the current UI, and for that it would be best to file a new issue, or upvote existing issues. After we get and process all the feedback we will decide which of the customisations we should explore to add. Thank you

[ahinkle]

Thanks @isidorn,

Users have been asking for years for customizable options in VSCode - it's no secret:

#519
#41909
#9285
#12377

A community extension was created to use the methods published by VSCode. It's unfortunate to see a breaking change to a largely used extension was pushed with minimal discussion in a 15-day timeframe with zero alternatives or fixes for users.

[kvndrsslr]

I second @ahinkle's opinion, it would have been good to initiate this dialogue first and after a solution is found, merge this.
Since the reasons communicated publicly for this are a mere 5% loading speed-up compared to un-mangled code it's even less understandable. I'm not sure anyone is actually hugely profiting from this - unless you guys actually want to kill monkey patching, in which case it should just be communicated like it is.

This software is a huge success and having developers as your user base can be overwhelming in terms of niche feature requests even for much smaller scale projects.
So I don't think Microsoft can, need or should tend to each of these UI customization requests individually. Just let developers do what they do best: hack systems to adjust them to their needs.

[stephenreid321]

Outrageous, so many of us rely on customize-ui and monkey-patch, please find a way to allow these to continue working

[DeltaRazero]

Unfortunately, development time of features in VSCode slow down towards the end of the year. Of course, that is no problem since things like backlog cleanup of bugs and smaller issues is important too. However, given the average time needed to implement features has increased since VSCode has grown significantly in scope, it's annoying for users to give up on our customizations to improve UX and wait months — possibly years — before it gets implemented in the official VSCode repo.

[hammypants]

@ahinkle thanks for reaching out. We already commented on the customize-ui extension here iocave/customize-ui#156 (comment) More details can be found here microsoft/vscode-discussions#257

We would love to learn more about the missing customisations of the current UI, and for that it would be best to file a new issue, or upvote existing issues. After we get and process all the feedback we will decide which of the customisations we should explore to add. Thank you

You guys have literally closed issues on this in our face.

[chengJim]

It cause customize-ui unusable, so how can we customize the font family of the UI now ?

[binaryben]

Such a joke to break an extension that is providing customisation options that have literally been requested for years! I'm glad to hear that this is finally causing the PM to take note, but please revert this PR in the mean time until solutions have been provided. The absence of the customisations I have is significantly slowing down my workflow to the point I will have to downgrade and disable automatic updates.

[binaryben]

Extend, embrace, extinguish. So much for being for the open sourced community M$.

[panoply]

Making my voice heard here. It's utterly wild and slightly baffling that folks needed to even rely on a monkey patch enhancements for the smallest tweaks like (for example) hiding the title bar. While this PR is great work overall, the fact that it has rendered the extension customize-ui inoperable is just ratchet.

While MS and the vscode team work tirelessly to deliver a great product the issue pertaining to the UI specifically the title bar for MacOS users is something that has persisted for several years. It's my hope that MS and the vscode team seriously consider exposing options for hiding the title bar and not continue to sit on the issue that quite literally has been the deciding factor of many when it come to choosing vscode over alternatives in the nexus. Personally, I didn't adopt vscode until I had the patch available.

Developers spend hours within the editors UI and our brains become accustomed. This is why folks have favourite themes, syntax colour quirks and font preferences. Developers coding in the confinements of laptop screens or those which don't leverage dual screens only have limited dimensions to work within and the title bar is a heathen which lives rent free and takes up space in an unapologetic manner.

v1.74.0 has disrupted the ui aesthetics for over 100k users who rely on customize-ui. Don't let vscode die on this hill.

[NuckChorris]

To everyone frustrated like me, you can download the previous version here and then set the following setting to prevent auto-updating:

"update.mode": "manual"

Sucks, but hopefully they revert it. I also recommend turning on Telemetry so they see us in their update adoption rate :)

[neon-sunset]

This PR makes VS Code incompatible with its Customize UI and Monkey Patch extensions which were the only reasonable way to make the UI experience pleasant with proper layout and correct client-side decorations.

After this change has landed, me and a couple of my friends are considering dropping the usage of VS Code on a permanent basis and are already forced to rely on other tools.

[mylanconnolly]

I appreciate the desire to make the distributed application smaller, however it would be greatly appreciated if there was a mechanism to make things like Customize UI work in a similar fashion, again. This caught me by surprise and the default look of VSCode isn't very pleasant for me. Hopefully something will come along

[talks2much]

@mylanconnolly I think originally there was no intention to make application faster or smaller (<1.8MB is just not measurable), but to hide VS Code sources in bundle instead. It also broke a lot of other extensions on the marketplace that were using private properties (probably by mistake or lack of public API) and made extensions much harder to debug.

Never thought code obfuscation will start happening in OSS project.

[rbreaves]

Locking my vscode version to 1.73 until this PR is either removed or made to work with Customize UI. Please remove this PR until/unless you collaborate with the Customize UI extension developer. @jrieken @alexr00 This addition makes VSCode unusable for me and however many tens of thousands.. maybe over 100k users that use Customize UI.

And yes, I agree with what @ahinkle says above.