Skip to content

Rule proposal: prefer-private-class-fields #979

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

Open
sindresorhus opened this issue Jan 1, 2021 · 7 comments
Open

Rule proposal: prefer-private-class-fields #979

sindresorhus opened this issue Jan 1, 2021 · 7 comments

Comments

@sindresorhus
Copy link
Owner

sindresorhus commented Jan 1, 2021

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields

Prefer private fields over the convention of underscore prefixed names.

This feature requires Node.js 12, so we cannot add it to the recommended preset until April 2021 (date of Node.js 10 obsoletion).

Does ESLint support this feature yet?

Fail

class Foo {
	static _PRIVATE_STATIC_FIELD

	_privateField

	_privateMethod() {
		return 'hello world'
	}
}

Pass

class Foo {
	static #PRIVATE_STATIC_FIELD

	#privateField

	#privateMethod() {
		return 'hello world'
	}
}
@sindresorhus
Copy link
Owner Author

This is now accepted.


But it's blocked by:

Does ESLint support this feature yet?

@fregante
Copy link
Collaborator

No longer blocked

@fisker
Copy link
Collaborator

fisker commented Dec 17, 2021

I've already tried to implement this the other day, my experience on using private fields, I really need proposal-destructuring-private

const {a, b, c, d} = this
const e = this.#e

awkward!

@sindresorhus
Copy link
Owner Author

@fisker I would argue having to use a _ prefix to pseudo hide properties/methods is also awkward. I don't think lack of destructuring is awkward enough to not use private fields. It's just a minor inconvenience. The proposal-destructuring-private thing will probably not land in Node.js until Node.js 20 at the earliest, which means packages will not be able to use it until 2025.

@bbugh
Copy link

bbugh commented Oct 4, 2022

One thing to consider is that #private fields and proxies do not work together. References:

  1. Private members break proxies tc39/proposal-class-fields#106
  2. Private fields incompatible with JS Proxy evanw/esbuild#1969

@jimmywarting
Copy link

in regards to destructuring-private

i have also had to do:

const a = this.#a
const b = this.#b
const c = this.#c

And I agree that it feels a bit awkward and inconvenient. but not something that's bothering me that much.
i did found that it could be just simpler to just have one single private property bag where i then store all my things

const {a, b, c} = this.#bag || { }

i rather prefer # over soft private keyword like in typescript that don't change anything.
esbuild can mangle private class fields down to just 1-2 letter words resulting in better compression and things stay private as it should be doing. and it's easier to recognize that some random piece of code is making use of private class fields in some middle of the code.

@jimmywarting
Copy link

{
  'no-restricted-syntax': [
    'error',
    {
      selector: ':matches(PropertyDefinition, MethodDefinition)[accessibility="private"]',
      message: 'Use #private instead',
    },
  ],
}

playground

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants