Skip to content

Bump ESLint and related dependencies, and fix lint errors#1014

Closed
Mrtenz wants to merge 32 commits intomainfrom
mrtenz/bump-eslint
Closed

Bump ESLint and related dependencies, and fix lint errors#1014
Mrtenz wants to merge 32 commits intomainfrom
mrtenz/bump-eslint

Conversation

@Mrtenz
Copy link
Copy Markdown
Member

@Mrtenz Mrtenz commented Dec 9, 2022

This bumps ESLint and related dependencies to the latest version. I've also removed some custom rules from the ESLint config, as they seem to be unnecessary.

Packages to fix:

  • address-book-controller
  • announcement-controller
  • approval-controller
  • assets-controller
  • base-controller
  • composable-controller
  • controller-utils
  • ens-controller
  • gas-fee-controller
  • keyring-controller
  • message-manager
  • network-controller
  • notification-controller
  • permission-controller
  • phishing-controller
  • preferences-controller
  • rate-limit-controller
  • subject-metadata-controller
  • transaction-controller

Breaking changes

While I tried to keep breaking changes to a minimum, there are a few:

  • Certain enum keys have been renamed. The values are still the same, however.
  • All methods with the private modifier have been changed to use a hash name instead, making them truly private. Any code relying on calling these private methods (by suppressing TypeScript errors), will break.

this.updateIdentities(await this.#keyring.getAccounts());
this.fullUpdate();
this.#updateIdentities(await this.#keyring.getAccounts());
await this.fullUpdate();
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This potentially changes the behaviour of this function. We may want to do this instead:

Suggested change
await this.fullUpdate();
this.fullUpdate().catch(console.error);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense to me.

this.updateIdentities(await this.#keyring.getAccounts());
this.fullUpdate();
this.#updateIdentities(await this.#keyring.getAccounts());
await this.fullUpdate();
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This potentially changes the behaviour of this function. We may want to do this instead:

Suggested change
await this.fullUpdate();
this.fullUpdate().catch(console.error);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me.

type: string;
accounts: string[];
getAccounts(): string[];
getAccounts(): string[] | Promise<string[]>;
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an assumption I made, since getAccounts() is awaited further on.

opts.requestData,
);
this._showApprovalRequest();
await this.#showApprovalRequest();
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This potentially changes the behaviour of this function. We may want to do this instead:

Suggested change
await this.#showApprovalRequest();
this.#showApprovalRequest().catch(console.error);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes sense.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside: Original looks like it could be a mistake? 🤔

I'd expect the two promises (this.#showApprovalRequest and this.#add) to be either serially resolved (await or then), or returned together via a Promise.all?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be, but that's probably something we can decide later.

@Mrtenz Mrtenz force-pushed the mrtenz/bump-eslint branch from f1acb29 to 70c1a33 Compare December 9, 2022 15:32
@Mrtenz Mrtenz marked this pull request as ready for review December 9, 2022 15:36
@Mrtenz Mrtenz requested a review from a team as a code owner December 9, 2022 15:36
@legobeat
Copy link
Copy Markdown
Contributor

legobeat commented Dec 10, 2022

Can the (potential) behavior changes be replaced with eslint-ignore directives for this PR to make it purely about linting, and split them out into one or a couple separate PRs?

Copy link
Copy Markdown
Contributor

@mcmire mcmire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good work on this. Most of the comments here are minor but there are a few cases that are more blocking than others.

'Invalid decimals "-1": must be 0 <= 36.',
);

// eslint-disable-next-line require-atomic-updates
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the lint message here? Wondering if there is a way to fix this other than bypassing.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ESLint: Possible race condition: asset.decimals might be assigned based on an outdated state of asset.(require-atomic-updates)

this.#subjectsWithoutPermissionsEncounteredSinceStartup.add(origin);

this.update((draftState) => {
// Typecast: ts(2589)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this comment still apply?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, I will remove it.

* Stores domain metadata for the given origin (subject). Deletes metadata for
* subjects without permissions in a FIFO manner once more than
* {@link SubjectMetadataController.subjectCacheLimit} distinct origins have
* {@link SubjectMetadataController.#subjectCacheLimit} distinct origins have
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this worth linking to if it's a private method? (Such a link may not be accessible in the generated docs.)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There may be other examples of this that I came across but didn't comment on. I'll take a look later to see if I can find them.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, probably not. I think either way (even with the private modifier), this wouldn't be included in the doc.

Comment on lines +607 to +608
chainId: parseInt(chainId, NaN),
networkId: parseInt(networkId, NaN),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is NaN appropriate here? Should this be 16 or 10?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. NaN is the equivalent of undefined, so that's why I used that.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting... I did not know that.

"esModuleInterop": true,
"noEmit": true
"noEmit": true,
"strictNullChecks": true
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh... I thought this was covered by strict.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@typescript-eslint was complaining without this.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is covered by strict, but we don't have strict enabled here. It's just in the packages tsconfig.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. Makes sense.

@mcmire
Copy link
Copy Markdown
Contributor

mcmire commented Dec 20, 2022

@Mrtenz I would love to see this merged! That said, I do agree with @legobeat in that the breaking changes in this PR are a bit difficult to discern due to the size. I also wonder if it would be beneficial to bypass these violations for now and then add them in a future PR so that they are more visible. Maybe we could even override the private field rule so that it's ignored for now and add that in its own PR since it affects so many files. I am happy to help with this, just let me know.

@legobeat
Copy link
Copy Markdown
Contributor

New attempt: #1498

@mcmire
Copy link
Copy Markdown
Contributor

mcmire commented Jul 31, 2023

Since #1498 has been merged, should we close this pull request?

@Mrtenz Mrtenz closed this Jan 15, 2025
@Mrtenz Mrtenz deleted the mrtenz/bump-eslint branch January 15, 2025 12:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants