Summary

Add a rule for detecting static access inside of @spina-wrapped classes.

Review Request #14640 — Created Oct. 17, 2025 and updated Nov. 3, 2025, 8:37 a.m.

Information

Owner

david

Repository

beanbag-eslint-plugin

Branch

master

Bugs

Depends On

Reviewers

Groups

beanbag-misc

People

Description

We discovered a confusing bug where accessing static members within a

class that was wrapped with the @spina decorator would end up getting

members on the inner class rather than the wrapper. This caused an issue

with tests where the tests were setting a static attribute on the

wrapper, and the inner class had a different value.
The fix is a surprising, unintuitive change to use this.constructor

for any static accesses within the class itself. Because this is

something I'll immediately forget, I wanted to have an eslint rule to

detect this situation in the future.
This change adds the new rule. It specifically only operates on classes

decorated with @spina (at least for now). It will detect static member

accesses within member functions and static functions. It also includes

a fixer that will add the declare ['constructor'] line to the

beginning of the class (if it's needed and not already present) and then

replace said accesses with this.constructor or this as appropriate.

Testing Done


Ran unit tests.
Saw that this correctly flagged the issue, and that asking my LSP to

  apply the fix worked correctly.

Commits

Summary	ID
Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions. It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's needed and not already present) and then replace said accesses with `this.constructor` or `this` as appropriate. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qmuowmxvvkztmqtsppskqtrpstqsoyll

Summary

Add a rule for detecting static access inside of @spina-wrapped classes.

We discovered a confusing bug where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions. It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's needed and not already present) and then replace said accesses with `this.constructor` or `this` as appropriate. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.

qmuowmxvvkztmqtsppskqtrpstqsoyll

Issues

Description	From	Last Updated
Can you add any necessary Version Added/Changed docs as appropriate in here, so we can better track changes?	chipx86	Nov. 3, 2025, 8:31 a.m.
Use the function form of "use strict". Column: 1 Error code: W097	reviewbot	Oct. 17, 2025, 3:28 p.m.
'require' is not defined. Column: 24 Error code: W117	reviewbot	Oct. 17, 2025, 3:28 p.m.
'require' is not defined. Column: 14 Error code: W117	reviewbot	Oct. 17, 2025, 3:28 p.m.
'describe' is not defined. Column: 23 Error code: W117	reviewbot	Oct. 17, 2025, 3:28 p.m.
'it' is not defined. Column: 17 Error code: W117	reviewbot	Oct. 17, 2025, 3:28 p.m.
'require' is not defined. Column: 17 Error code: W117	reviewbot	Oct. 17, 2025, 3:28 p.m.
'describe' is not defined. Column: 1 Error code: W117	reviewbot	Oct. 17, 2025, 3:28 p.m.
There's a comment on the parent change here, but so it doesn't get lost in this: Blank line between bullet …	chipx86	Nov. 3, 2025, 8:31 a.m.

flake8 passed.

JSHint failed.

JSHint

tests/rules/spina-wrapped-static-access.spec.js (Diff revision 1)
The issue has been dropped. Show all issues
```
Use the function form of "use strict".

Column: 1
Error code: W097
```
tests/rules/spina-wrapped-static-access.spec.js (Diff revision 1)
The issue has been dropped. Show all issues
```
'require' is not defined.

Column: 24
Error code: W117
```
tests/rules/spina-wrapped-static-access.spec.js (Diff revision 1)
The issue has been dropped. Show all issues
```
'require' is not defined.

Column: 14
Error code: W117
```
tests/rules/spina-wrapped-static-access.spec.js (Diff revision 1)
The issue has been dropped. Show all issues
```
'describe' is not defined.

Column: 23
Error code: W117
```
tests/rules/spina-wrapped-static-access.spec.js (Diff revision 1)
The issue has been dropped. Show all issues
```
'it' is not defined.

Column: 17
Error code: W117
```
tests/rules/spina-wrapped-static-access.spec.js (Diff revision 1)
The issue has been dropped. Show all issues
```
'require' is not defined.

Column: 17
Error code: W117
```
tests/rules/spina-wrapped-static-access.spec.js (Diff revision 1)
The issue has been dropped. Show all issues
```
'describe' is not defined.

Column: 1
Error code: W117
```

Commits:

	Summary	ID
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug last night where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions (although inside static functions we can't do anything about it). It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's not already present) and then replace said accesses with `this.constructor`. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qxotmtlxowuzsvmxtoprplmnukvnzmxn
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug last night where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions (although inside static functions we can't do anything about it). It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's not already present) and then replace said accesses with `this.constructor`. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qxotmtlxowuzsvmxtoprplmnukvnzmxn

Diff:

Revision 2 (+2372 -34)

Show changes

	NEWS.md
	eslint.config.mjs
	package.json
	package-lock.json
	rollup.config.js
	spec/support/jasmine.mjs
	src/index.ts
	src/rules/spina-wrapped-static-access.ts
	1 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Change Summary:

Split into two rules so the static-method case can be a suggestion and the regular method case can be a problem.

Commits:

	Summary	ID
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug last night where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions (although inside static functions we can't do anything about it). It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's not already present) and then replace said accesses with `this.constructor`. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qxotmtlxowuzsvmxtoprplmnukvnzmxn
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug last night where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions (although inside static functions we can't do anything about it). It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's not already present) and then replace said accesses with `this.constructor`. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qxotmtlxowuzsvmxtoprplmnukvnzmxn

Diff:

Revision 3 (+3258 -38)

Show changes

	NEWS.md
	eslint.config.mjs
	package.json
	package-lock.json
	rollup.config.js
	spec/support/jasmine.mjs
	src/index.ts
	src/utils.ts
	4 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Description:

		We discovered a confusing bug last night where accessing static members
		within a class that was wrapped with the `@spina` decorator would end up
		getting members on the inner class rather than the wrapper. This caused
		an issue with tests where the tests were setting a static attribute on
		the wrapper, and the inner class had a different value.

		The fix is a surprising, unintuitive change to use `this.constructor`
		for any static accesses within the class itself. Because this is
		something I'll immediately forget, I wanted to have an eslint rule to
		detect this situation in the future.

		This change adds the new rule. It specifically only operates on classes
		decorated with `@spina` (at least for now). It will detect static member
~		accesses within member functions and static functions (although inside
~		static functions we can't do anything about it). It also includes a
~		fixer that will add the `declare ['constructor']` line to the beginning
~		of the class (if it's not already present) and then replace said
	~	accesses within member functions and static functions. It also includes
	~	a fixer that will add the `declare ['constructor']` line to the
	~	beginning of the class (if it's needed and not already present) and then
	~	replace said accesses with `this.constructor` or `this` as appropriate.
-		accesses with `this.constructor`.

Commits:

	Summary	ID
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug last night where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions (although inside static functions we can't do anything about it). It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's not already present) and then replace said accesses with `this.constructor`. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qxotmtlxowuzsvmxtoprplmnukvnzmxn
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug last night where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions. It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's needed and not already present) and then replace said accesses with `this.constructor` or `this` as appropriate. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qxotmtlxowuzsvmxtoprplmnukvnzmxn

Diff:

Revision 4 (+2434 -38)

Show changes

	NEWS.md
	eslint.config.mjs
	package.json
	package-lock.json
	rollup.config.js
	spec/support/jasmine.mjs
	src/index.ts
	src/rules/spina-wrapped-static-access.ts
	1 more

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Description:: ~
We discovered a confusing bug last night where accessing static members
~ within a class that was wrapped with the @spina decorator would end up
~ getting members on the inner class rather than the wrapper. This caused
~ an issue with tests where the tests were setting a static attribute on
~ the wrapper, and the inner class had a different value.
~
We discovered a confusing bug where accessing static members within a
~ class that was wrapped with the @spina decorator would end up getting
~ members on the inner class rather than the wrapper. This caused an issue
~ with tests where the tests were setting a static attribute on the
~ wrapper, and the inner class had a different value.

The fix is a surprising, unintuitive change to use this.constructor
for any static accesses within the class itself. Because this is
something I'll immediately forget, I wanted to have an eslint rule to
detect this situation in the future.

This change adds the new rule. It specifically only operates on classes
decorated with @spina (at least for now). It will detect static member
accesses within member functions and static functions. It also includes
a fixer that will add the declare ['constructor'] line to the
beginning of the class (if it's needed and not already present) and then
replace said accesses with this.constructor or this as appropriate.

Ship it!

```
Ship It!
```

Change Summary:


Update for new plugin layout changes.
Fix the fixer to detect surrounding indentation instead of assuming 4 spaces.

Commits:

	Summary	ID
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug last night where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions. It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's needed and not already present) and then replace said accesses with `this.constructor` or `this` as appropriate. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qxotmtlxowuzsvmxtoprplmnukvnzmxn
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions. It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's needed and not already present) and then replace said accesses with `this.constructor` or `this` as appropriate. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qxotmtlxowuzsvmxtoprplmnukvnzmxn

Diff:

Revision 5 (+1586 -4)

Show changes

	NEWS.md
	package.json
	spec/support/jasmine.mjs
	src/index.ts
	src/rules/index.ts
	src/rules/spina-wrapped-static-access.ts
	tests/rules/spina-wrapped-static-access.spec.js

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

```
Very nice change.
```

The issue has been resolved. Show all issues

Can you add any necessary Version Added/Changed docs as appropriate in here, so we can better track changes?

NEWS.md (Diff revision 5)

The issue has been resolved. Show all issues

There's a comment on the parent change here, but so it doesn't get lost in this:

Blank line between bullet points.
Two blank lines before the next section header.

Commits:

	Summary	ID
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions. It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's needed and not already present) and then replace said accesses with `this.constructor` or `this` as appropriate. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qxotmtlxowuzsvmxtoprplmnukvnzmxn
	Add a rule for detecting static access inside of @spina-wrapped classes. We discovered a confusing bug where accessing static members within a class that was wrapped with the `@spina` decorator would end up getting members on the inner class rather than the wrapper. This caused an issue with tests where the tests were setting a static attribute on the wrapper, and the inner class had a different value. The fix is a surprising, unintuitive change to use `this.constructor` for any static accesses within the class itself. Because this is something I'll immediately forget, I wanted to have an eslint rule to detect this situation in the future. This change adds the new rule. It specifically only operates on classes decorated with `@spina` (at least for now). It will detect static member accesses within member functions and static functions. It also includes a fixer that will add the `declare ['constructor']` line to the beginning of the class (if it's needed and not already present) and then replace said accesses with `this.constructor` or `this` as appropriate. Testing Done: - Ran unit tests. - Saw that this correctly flagged the issue, and that asking my LSP to apply the fix worked correctly.	qmuowmxvvkztmqtsppskqtrpstqsoyll

Diff:

Revision 6 (+1594 -6)

Show changes

	NEWS.md
	package.json
	spec/support/jasmine.mjs
	src/index.ts
	src/rules/index.ts
	src/rules/spina-wrapped-static-access.ts
	tests/rules/spina-wrapped-static-access.spec.js

Checks run (2 succeeded)

flake8 passed.

JSHint passed.