gajus / eslint-plugin-canonical Goto Github PK

https://github.com/gajus/eslint-plugin-canonical/blob/6bf9db851be476ee41fb6f64c610e0eb7a1c9897/.README/rules/prefer-import-alias.md#prefer-import-alias

Hey Boss, curious if this is dead? Was using it and was correctly correcting non aliased imports. But seems its gone now? Is there a better approach?

This rule clashes with @typescript-eslint/consistent-type-imports. When using both together, you get things like import type { type X } and import { type type X }.

Hi, thank you for this awesome plugin!

It would be really nice to integrate eslint-plugin-unused-imports,

which also lint unused vars for imports.

Thanks.

Bug report or Feature request?

Feature request

Information

virtual-module feature should allow for nested virtual modules
a parent virtual modules should be able to re-export members from nested - child - virtual modules

components/
├── Foo/
│ └── index.ts
│ └── Qux/
│ └── index.ts/
│ └── Quux/
│ └── index.ts
└── Bar

Qux should be able to re-export from Quux
Foo should be able to re-export from Qux
Bar should be able to import from Foo

if specific members of Quux are re-exported by Qux
and
same specific members are re-exported by Foo
then
Bar should be able to import them from Foo

currently, this is not supported as we get
Cannot import a private path. /index.ts belongs to parent virtual module
when re-exporting from nested virtual module

Hey, I was checking out the eslint-config-canonical package and came across this.

lodash is being imported at runtime by rules/filenameMatchExported.js, but it's not listed in dependencies.

This turn into a problem when using PNPM as package manager for the project, because the node_modules layout it creates doesn't let eslint-plugin-canonical have access to lodash.

Oops! Something went wrong! :(

ESLint: 8.6.0

Error: Failed to load plugin 'canonical' declared in '.eslintrc.yaml » eslint-config-canonical': Cannot find module 'lodash'
Require stack:
- /project/node_modules/.pnpm/[email protected][email protected]/node_modules/eslint-plugin-canonical/dist/rules/filenameMatchExported.js
- /project/node_modules/.pnpm/[email protected][email protected]/node_modules/eslint-plugin-canonical/dist/index.js
- /project/node_modules/.pnpm/@[email protected]/node_modules/@eslint/eslintrc/dist/eslintrc.cjs
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (/project/node_modules/.pnpm/[email protected]/node_modules/v8-compile-cache/v8-compile-cache.js:159:20)
    at Object.<anonymous> (/project/node_modules/.pnpm/[email protected][email protected]/node_modules/eslint-plugin-canonical/dist/rules/filenameMatchExported.js:10:15)
    at Module._compile (/project/node_modules/.pnpm/[email protected]/node_modules/v8-compile-cache/v8-compile-cache.js:192:30)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)

Error: .eslintrc.js » plugin:canonical/recommended:
        Configuration for rule "canonical/id-match" is invalid:
        Value {"caseSensitive":false,"natural":true,"classFields":false,"ignoreDestructuring":false,"ignoreNamedImports":false,"onlyDeclarations":false,"properties":false} should NOT have additional properties.

This same typo is also present in README Configuration section.

From looking at https://www.npmjs.com/package/eslint-plugin-canonical (specifically the "Versions" tab), you can see that 2.6.0 is tagged as the latest version. I'm not sure what version (or state of the repo) this version actually maps to, but at the very least, it doesn't include the new prefer-inline-type-import rule (which is how I noticed this). Should the latest version (the version that NPM "installs" by default) not be 3.0.0?

Version 3.2.0 pushed to NPM contains the entire repo instead of the built distribution.

You can see this easily by comparing the release files on NPM:

Version 3.2.0 files on NPM
Version 3.1.0 files on NPM

It would be nice to be able to ignore all imports. For example:

'canonical/id-match': ['error', '^[a-z]+([A-Z][a-z]+)*$', {
      ignoreImports: true,
}]

Would allow

import React from 'react'

Is there any chance to add an ability to have kebab filename for pascal type of export (react component)?

Rule sample:
"canonical/filename-match-exported": [ 2, { "transforms": "kebab" } ]

Filename sample:
thumb-up.tsx

Export sample:
export default ThumbUp

Current state:
Error:
1:1 error Filename 'thumb-up' must match the exported and transformed name 'thumbUp' canonical/filename-match-exported

Expected: No error

👋 @gajus!

I faced an odd issue with this plugin after upgrading ESLint dependencies in hashintel/hash#1796 via Renovate. CI output was full of errors like:

  1:1  error  Definition for rule 'canonical/filename-no-index' was not found  canonical/filename-no-index

/home/runner/work/hash/hash/packages/hash/frontend/src/components/page-icon.tsx
  1:1  error  Definition for rule 'canonical/filename-no-index' was not found  canonical/filename-no-index

/home/runner/work/hash/hash/packages/hash/frontend/src/components/page-loading-state.tsx
  1:1  error  Definition for rule 'canonical/filename-no-index' was not found  canonical/filename-no-index

/home/runner/work/hash/hash/packages/hash/frontend/src/components/remote-block/block-renderer.tsx
  1:1  error  Definition for rule 'canonical/filename-no-index' was not found  canonical/filename-no-index

/home/runner/work/hash/hash/packages/hash/frontend/src/components/remote-block/block-renderer/custom-element.tsx
  1:1  error  Definition for rule 'canonical/filename-no-index' was not found  canonical/filename-no-index

/home/runner/work/hash/hash/packages/hash/frontend/src/components/remote-block/block-renderer/html.tsx
  1:1  error  Definition for rule 'canonical/filename-no-index' was not found  canonical/filename-no-index

/home/runner/work/hash/hash/packages/hash/frontend/src/components/remote-block/loadremote-block.ts
  1:1  error  Definition for rule 'canonical/filename-no-index' was not found  canonical/filename-no-index

/home/runner/work/hash/hash/packages/hash/frontend/src/components/remote-block/remote-block.tsx
  1:1  error  Definition for rule 'canonical/filename-no-index' was not found  canonical/filename-no-index

After downgrading eslint-plugin-canonical from 3.2.1 back to 3.1.0, CI went back to normal.

I did not investigate this case further, but I still decided to open an issue to potentially help other folks. Feel free to close it if I’ve missed something!

After moving eslint-plugin-filenames -> eslint-plugin-canonical, I found that the volume of linting dependencies has almost doubled from what it was - but it was dependencies of eslint with 14 heavy plugins.

zloirock/core-js@3e58c09, see tests/eslint/package-lock.json.

Is it possible somehow reduce it?

Hi,

the README says:

Set parser property to babel-eslint.

what is the reason for that?

I haven't changed the default parser and it seems your plugin can detect errors already.

The readme currently says that you can use:

"canonical/filename-match-exported": [2, { "transforms": [ null, "kebab", "snake" ] } ]

This doesn’t actually work, because the config schema only supports strings in the transforms array. ESLint crashes with an error.

You can work around this today by adding any string outside of the normal config map to the array, like so:

"canonical/filename-match-exported": [2, { "transforms": [ "null", "kebab", "snake" ] } ]

This causes the plugin to resolve that transform to undefined, which it treats the same as null for the purposes of transforming.

Just raising the issue so you’re aware of it. This is probably extremely low priority.

@gajus : Although I see you've since moved to a 3.0.0 version, a 2.5.0 version of eslint-plugin-canonical was nevertheless released with breaking changes (the node: specifiers). This causes all projects targeting ^2.0.0, such as eslint-plugin-jsdoc to suddenly start breaking.

Could you put out a 2.6.0 release which reverts those node: changes, as the EOL that is coming at the end of this month is only to drop Node 12, not yet to drop Node 14?

Thanks!

After trying to add this rule to my work codebase, I encountered the following cases where there was no easy way to resolve the lint warnings:

1. Importing a default export and only using its type. There are a few cases where default exports can't be avoided - for example, importing the type of a JSON file (import type package from "./package.json";), or a library import than you don't control. In this case, I would personally expect the rule to accept this as valid.
2. Glob type-only imports, for example, import type * as Types from "./types";. While this is something that can more easily be worked around compared to the case above (by just explicitly importing the required types), I do still think it is something the rule should handle. As with the above case, I would personally expect the rule to accept this as valid (even if it is via an option).

In mysticatea/eslint-plugin-eslint-comments#65 you asked about this incorporation, and the author suggests you to do so, and it seems the project won't be receiving much attention: mysticatea/eslint-plugin-eslint-comments#72 (comment)

It would be great to have these rules in ESLint v8.

Port https://www.npmjs.com/package/eslint-plugin-no-iife

The eslint sort-keys docs allow for a configuration option of allowLineSeparatedGroups. It doesn't seem like this option is available in canonical/sort-keys.

When a file uses the syntax

export * from "./file.ts";

where file.ts contains more than one export on separate lines, the rule throws a RangeError.

Minimal reproduction: https://github.com/omothm/no-unused-exports-export-from-bug-repro

The id-match rule is erring out with this code:

       const {
          index,
          '0': n0,
          '1': n1,
        } = exampleCode;