I've had to unsubscribe from many issues I'd like to follow because of spam caused by information-free comments.
> We are doing this to save bandwidth and startup time. Mangling allowed us reduce the size of our renderer JS bundles by ~13% (-1.5MB). This yields in ~5% faster code loading. Similar numbers apply to the main and extension host bundles.
These were private properties, not part of the exposed API. Plugins that depended on these were prone to breakage anyway, as is the case with using any private API.
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
MS is pushing a change that will break any extensions that were diving into said guts (but also shrink their code a bit).
One such extension was described by its own creator as
> basically a pile of hacks that works by monkey-patching javascript in browser and main processes, which is something that regular extensions can not do, and probably for a good reason :)
-
I clicked on the link fully prepared to be outraged, but I walked away 50/50 on it: it's true that even if you don't officially support a hack, if enough people use said hack, you'll break things for real users when you change stuff that was supposed to be an implementation detail.
I'm guessing this is being done to free them of cases where that was already being worked around internally, and not outright malice judging by the language being used
There are extensions that used some of these private properties to change the UI of the editor, as well as other things I'm sure, and now they won't work since the property names are mangled.
They probably didn't do this to intentionally break those extensions, but it was a side effect.
"Initiate Emacs."
The GNU splash buffer smiles lovingly at me.
In this case name mangling might be disabled by removing one line https://github.com/microsoft/vscode/pull/166126/files#diff-e.... Or if not it's still trivial to remove everything added by this commit.
In fact, there's already an actively-maintained fork of VSCode which removes the telemetry (VSCodium), they could easily remove the name mangling as well.
They already did.
edit: And it's strikes me as odd that you'd want to basically screw over all the demographic of what is your "power users", meaning those that have the ability and the desire to tweak things.
In no way was this pull request intentionally targetting compatibility with this extension. But adding exactly this and similar customizations has been requested since 2015 [2] and the requests are either ignored or dismissed, not out of malice. I understand the frustration of feedback being ignored and having to deal with UI or compatibility breaking changes for the sake of some improvement without clear impact. User customizable UI/UX is worth an extra few seconds loading time, in my opinion and the only option is downgrading. Some other people seem to agree and have similarly chosen to downgrade (15 thumbs up in that locked pull request thread). Title is wrongly sensationalized.
1. https://marketplace.visualstudio.com/items?itemName=iocave.c...
Ironically, these bugs only seem to occur on windows. It seems the devs (all microsoft employees) all run mac and/or linux! There was a running joke on the issue trackers suggesting we donate windows licenses to the devs.
Compare to Linus's approach: https://lkml.org/lkml/2012/12/23/75
These extensions were depending on variable names that weren't part of the API.
