Esbuild: Private props

Created on 29 Mar 2020  路  6Comments  路  Source: evanw/esbuild

Private fields are Stage3 proposal, supported by major browsers https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Class_fields. Any plans to support it?

Most helpful comment

Yes, definitely. I will support this at least as a pass-through transformation, and maybe also with a lowering pass (using WeakMap like TypeScript). Just haven't gotten to it yet.

All 6 comments

Yes, definitely. I will support this at least as a pass-through transformation, and maybe also with a lowering pass (using WeakMap like TypeScript). Just haven't gotten to it yet.

I'd too love this feature

Small update: the private name syntax can now be parsed in the latest release (version 0.4.9). I haven't implemented the transform for older browsers yet, however.

This should be working as of esbuild version 0.5.7. I have added support for all kinds of private names (fields, methods, and getters/setters both non-static and static, including interactions with optional chaining). Please try it out and report bugs if you find any.

Given that the readme goes out of it's way to point out how slow WeakMap can be I'm curious what other approaches were evaluated? One pattern that I've seen for private fields is to use Symbol, like so:

const privateField = Symbol("MyClass/privateField");

class MyClass {
  constructor() {
    this.publicField = 0;
    this[privateField] = 1;
  }
}

Some quick benchmarking show that this performs closer to regular fields than the WeakMap approach. I know that it's observable via use of Object.getOwnPropertySymbols(), however, which may be the reason enough to avoid this approach if esbuild requires strict semantic equivalence.

Some quick benchmarking show that this performs closer to regular fields than the WeakMap approach. I know that it's observable via use of Object.getOwnPropertySymbols(), however, which may be the reason enough to avoid this approach if esbuild requires strict semantic equivalence.

Yes, I have considered that too, but I avoided it for the reason you mentioned. Turning private fields into something that's not private seems like an invalid transformation to me. I could see it being an opt-in transform perhaps.

Part of my hesitation is I've never seen this feature actually used in real-world code. If this feature makes it into more real-world code and 99% of the uses out there don't actually have to do with privacy, then I could see changing the default transformation and have privacy be opt-in instead. But I think it remains to be seen how this feature will actually be used once it gets more wide-spread adoption.

Edit: I see that Babel has a loose option that does this, so it's not without precedent. It would be interesting to hear from others that are using this feature in their code what they are using it for and why they are using it.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

a7ul picture a7ul  路  3Comments

ojanvafai picture ojanvafai  路  3Comments

mohsen1 picture mohsen1  路  3Comments

OneOfOne picture OneOfOne  路  3Comments

egoist picture egoist  路  3Comments