-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for properties mangling #218
Comments
Thanks for logging this issue. I'm aware of this transform and I have been considering implementing it. It should be somewhat straightforward I think, except there are some special cases to handle with automatically-generated properties that appear during bundling. |
This would be a really helpful improvement! I was kind of surprised that it didn't already happen. It seems like it could be safely on-by-default while breaking a very small amount of code for:
Those defaults would probably get me 100% of what I'd need and want, without breaking anything, and without having to dig any deeper into configuration. |
This should already happen in esbuild when |
Oh, you're totally right. I didn't even realize that I'd updated to a new enough version of TypeScript that doesn't barf on that syntax. My apologies for not retrying that. Private class fields are indeed getting renamed, to I converted a small TypeScript codebase to use
So my recommendation / request would be:
(I'm aware that those numbers all depend wildly based on the codebase and how long one's field names tend to be. Just trying to be helpful, not demanding! 🙂) |
Mangling properties leads to a double-digit (~15%) improvement in the minified and gizpped size of the main bundle of the thing I'm working on, it'd be nice to be able to just use esbuild and still gain the same benefits rather than piping esbuild's output to something like terser. |
In theory, it should be possible get much higher gains with TypeScript code than with JS and See the description of tscc, which tries to implement this. (I haven't tried it myself yet.) I don't know whether ESBuild internally preserves or discards type-information? If types aren't part of it it's internal representation, then something like tscc probably isn't possible without major changes... |
@mindplay-dk types just get stripped out in esbuild. I didn't know about tscc, it sounds interesting, but something like that should be officially supported to be made reliable I think, and unfortunately the typescript folks aren't that interested in that microsoft/TypeScript#8 |
Also https://github.com/timocov/ts-transformer-properties-rename |
Aha, yes, transformers sort of is what I thought plugins were, I guess 😊 |
TypeScript is fundamentally unsound by design, so I believe type information cannot be safely used to make code transformation decisions. Here's an example of the unsoundness: #771 (comment). |
This feature has been implemented and is now documented here: https://esbuild.github.io/api/#mangle-props |
Hey @evanw, thanks for fixing this. Is there any reason why esbuild doesn't handle a key in I do understand that it seems that your behaviour is close to Google Closure Compiler is some way, but this looks like a requirement of Google Closure Compiler to make the code works. |
Yes, I had Google Closure Compiler's behavior in mind when building this. From Google's documentation:
The rule is "quoted property names are not mangled" and |
@evanw This is not the same as The reason why I asked this is that it looks like the following pattern might be quite common for some of users, especially if you're using typescript (but not only): interface Foo {
prop: string;
}
interface Baz {
prop2: number;
}
declare const value: Foo | Baz;
if ('prop' in value) {
// value is type of Foo here and the compiler understands that
value.prop;
} and we cannot use And this pattern looks common for a JavaScript code as well, not just for TypeScript. If you want to use Google Closure Compiler in advanced mode you have to follow its limitations and rules (and this not the only one), but it won't be a JavaScript code, it will be a code which works in Google Closure Compiler (not only there, but especially there), i.e. kind of subset of JavaScript. So you could use esbuild with properties mangling for the code "adapted" for Google Closure Compiler's limitations only, and that's what I wanted to say. But if you're fine with that and you did this intentionally then OK. Probably an option to specify where it should be handled might be a solution though. |
You make a good case for this. Thanks for the additional information. I'm adding a |
Terser doc: https://terser.org/docs/cli-usage#cli-mangling-property-names-mangle-props
The text was updated successfully, but these errors were encountered: