itwin / eslint-plugin Goto Github PK

See https://github.com/iTwin/presentation/blob/master/.husky/pre-commit

The current no-internal-report logic assumes tsconfig.json is defined. It isn't always, some people use different names so we should allow specifying it

seems to emit nothing and the eslint child process exits non-zero unless I remove the custom formatter path, but haven't investigated further.

APIs marked internal are permitted to be used by any package in the itwinjs-core repository. Currently, this is not taken account by the no-internal rule. See this issue for examples of the problem

Following error message appears when trying to use @itwin/eslint-plugin 3.7.8 and typescript 5 in the same project:
WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree. You may find that it works just fine, or you may not. SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <4.5.0 YOUR TYPESCRIPT VERSION: 5.0.4 Please only submit bug reports when using the officially supported version.

Upgrading to version '^4.0.0-dev.44' gives a new error message:
ESLint couldn't find the config "plugin:@itwin/ui" to extend from. Please check that the name of the config is correct.

To solve the problem I had to remove this section from my package.json:
eslintConfig": { "plugins": [ "@itwin" ], "extends": "plugin:@itwin/ui" },
and also needed to upgrade to eslint '^8.44.0' and create a eslint.config.js file (this last bit is mentioned in the README.MD, not quite clear which version of @itwin/eslint-plugin requires it though)

The upgrade path is a bit rough. and its still unclear if it's fine to go with a dev version (i.e 4.0.0-dev.44') into production.

Inspired from #33. We need some tests to verify changes to config files. Or else it could lead to unexpected results in repos that use this plugin.

This is an issue that has happened to me intermittently, and when it happens I can't make it stop happening, but then it will magically stop happening on its own and I can't make it happen. The issue is that I have a line of code in the mobile sample app that makes a call to a deprecated function, so above that line of code I have an eslint comment to disable the deprecation rule:

            // eslint-disable-next-line deprecation/deprecation
            return await iModel.views.getThumbnail(viewSpecId);

Sometimes the above works fine, and npm run build works fine, along with npm run start (I'm still using react-scripts). Other times it complains that ther is no such deprecation/deprecation rule. Initially this only happened during npm run start, but today I had it happen with npm run build. For now, I have rolled back my @itwin/eslint-plugin version to 4.0.0-dev.33.

Other libraries can use @internal differently than iTwin.js, e.g. in generated prototype buffer code for typescript there is @internal (meaning generated) API usage.

We should allow passing a white-list of packages or package patterns (e.g. @itwin/*) to the no-internal rule's configuration to only check for @internal API usage from specific packages where it is known to be problematic.

The no-internal rule reports only one violation for multiple internal API usages of the same API within a file, after #23. The goal of that PR was to prevent multiple violations per a single usage, not across multiple usages. This is a regression that needs to be fixed, and it was mistake in hindsight to not add multiple internal API usages to the tests.

For example, the following code when linted with iTwin.js recommended produces one error:

import { IModelDb } from "@itwin/core-backend";

export class MyIModelDb extends IModelDb {
  public methodUsingInternal() {
    const first = this._locks;
    const second = this._locks;
    return [first, second, this._locks];
  }
}

export const _db1 = (undefined as any as IModelDb)._locks;

The output:

> [email protected] lint /tmp/test-eslint
> eslint index.ts


/tmp/test-eslint/index.ts
  10:19  error  property "IModelDb._locks" is internal  @itwin/no-internal

✖ 1 problem (1 error, 0 warnings)

3 out of 4 usages of _locks are not listed. Granted, you still get an error, and if you fix that error you will find another, so perhaps this is non-crticial, but the behavior is not ideal.

It looks like this feature: https://github.com/iTwin/itwinjs-core/pull/5032/files, which merged about 2 days before the initial commit in this repo, never made it into this repo.

This feature was originally used by the transformer which was removed from the core repo which is why it's no longer used, but others recently ran into the same issues that the transformer did which caused this to be implemented. We should patch it back in.

Currently all source code is in JavaScript. Explore converting them all to TypeScript for better type checking and DX

Aside from having a terrible package name, this library is quite outdated. We've run into an issue with its use of requireindex which also is quite outdated. I'm sure we can find some new rules (or god forbid catch these issues in PR) which do the same as:

• forbid-methods: By default, this rule aims to limit the use of React un-prefixed deprecated lifecycle methods:
• no-sanitizer-window-location: This rule aims to avoid Address DOM XSS attack. Using window.location improperly can cause javascript to trigger DOM based XSS attacks. Since window.location is readable and writable, it requires paying attention to what data is being assigned. Please find examples below as bad and best practices.
• no-sanitizer-with-danger: This rule aims to prevent Cross-Site Scripting (XSS) attacks from hackers (using dangerousSetInnerHTML)

With namespaces, we do not allow a member to be exported for extensions without the namespace itself being tagged. However, we do not enforce the same rule for classes.

Example:

export class Foo { // should have error similar to namespace, but no error is present
 /*
 * @extensions
 * @public
 */
 public static bar(){ // no error ok, method is properly tagged
  ...
  }
 }

Markdown renderers are numerous and at times very flexible with what is valid markup. It'd be nice to standardize markdown across our documentation and ensure that the markdown will be rendered appropriately by docs' markdown renderer (marked, I believe).

We currently wrap the no-internal rule in a build step, so these are not formatted like normal eslint errors, but we noticed that the JavaScript API for eslint when running this rule, is returning multiple different source slices for the same violation.

▲ [WARNING] function "createCustomItem" is beta.

    /REDACTED/packages/REDACTED/frontend/extensions/ContentTools.tsx:50:8:
      50 │         StatusBarItemUtilities.createCustomItem("Sections", StatusBarSection.Left, 30, <Sections hideW...
         ╵         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


▲ [WARNING] function "createCustomItem" is beta.

    /REDACTED/packages/REDACTED/frontend/extensions/ContentTools.tsx:50:8:
      50 │         StatusBarItemUtilities.createCustomItem("Sections", StatusBarSection.Left, 30, <Sections hideW...
         ╵         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Is there a bug where the parent back-tracking performed by the no-internal rule will report multiple violations where only one is necessary?

stdout, stderr, and the node error should all be printed when no-internal-report fails. Also process.exitCode should be set to the exit code of the invoked eslint process

This plugin does not work with @bentley/react-scripts@5. It produces errors in react-scripts start and react-scripts build saying that the plugin versions don't match between the two packages. I was able to work around the problem by adding the following to my package.json:

  "overrides": {
    "eslint-plugin-react": "7.32.1"
  },

I'm guessing that if this package (@itwin/eslint-plugin) updates to eslint-plugin-react version 7.32.1, the above workaround will no longer be necessary. Given that this package is designed to work with iTwin stuff, and iTwin stuff is designed to work with @bentley/react-scripts@5, I feel that the two should work together without requiring workarounds like the above.

CC: @aruniverse, @toddsouthenbentley

The current output of the lint rule is very verbose and not easily consumable in a CI build or locally. We should introduce a better summary of the output that is de-duped.

Add a summary table that groups by the package.
Add to the summary the count of internal, alpha and beta usage

The no-internal-report script is useful for summarizing the lengthy output of the no-internal ESLint rule. It currently only supports the tag option, while recently two other options were added to the rule that may be useful in the report. These other options are dontAllowWorkspaceInternal and checkedPackagePatterns which are explained here. They could be added as command line arguments to no-internal-report.

The latest prereleases drop support for nested (non-flat) config. I was told it was not investigated whether we can keep backwards compatibility. There are several fixes/features that could be used by teams not ready to jump to flat config.

This library is unusable with TypeScript 5.3.x:

TypeError: ts.getResolvedModule is not a function

TypeScript has moved the ts.getResolvedModule method to an internal API available off the program object.

To reproduce:

Upgrade TypeScript to 5.3.x in any project consuming this library, then run eslint.

References:

microsoft/rushstack#4404 (comment)

https://github.com/microsoft/TypeScript/pull/55818/files#diff-dbfa0e7f632eca196a5ee0e08e00743c46c03799e2704206cfccc065bb6f9e3a

1. Add an "e2e" test that spins up a (verdaccio) local npm registry,
2. publish the test fixture fake dependency packages (with fake @internal APIs) to that registry
3. have pnpm, rush, npm, (yarn?) etc all independently used to install the fake dependencies packages for the test fixture, and then run the no-internal tests on each linked workspace.

When pipeline is run and commits are being made by imodeljs-admin, the email is not recognized as correct and the build fails. Example: https://github.com/iTwin/eslint-plugin/actions/runs/7919189086/job/21619368733

This happens despite the fact that the email is configured properly earlier in script execution. Investigate and fix issue