I can't run the tests, perhaps a Windows issue?

[hornta]

I just cloned the repository and these commands.

• npm i
• npm test (this one failed with the output below)

PS Z:\git\eslint-plugin-import> npm test

> [email protected] pretest
> linklocal

tests\files\order-redirect
resolvers\webpack
tests\files\symlinked-module
tests\files\order-redirect-scoped
utils
resolvers\node

Linked 6 dependencies

> [email protected] test
> npm run tests-only


> [email protected] tests-only
> npm run mocha tests/src


> [email protected] mocha
> cross-env BABEL_ENV=test nyc mocha tests/src

Z:\git\eslint-plugin-import\node_modules\babel-core\lib\transformation\file\options\build-config-chain.js:154
      throw err;
      ^

SyntaxError: Z:\git\eslint-plugin-import\resolvers\webpack\.babelrc: Error while parsing JSON - Bad number at line 1 column 3 of the JSON5 data. Still to read: "./../.babelrc"
    at error (Z:\git\eslint-plugin-import\node_modules\json5\lib\json5.js:56:25)
    at number (Z:\git\eslint-plugin-import\node_modules\json5\lib\json5.js:212:17)
    at value (Z:\git\eslint-plugin-import\node_modules\json5\lib\json5.js:491:20)
    at Object.parse (Z:\git\eslint-plugin-import\node_modules\json5\lib\json5.js:508:18)
    at ConfigChainBuilder.addConfig (Z:\git\eslint-plugin-import\node_modules\babel-core\lib\transformation\file\options\build-config-chain.js:150:65)   
    at ConfigChainBuilder.findConfigs (Z:\git\eslint-plugin-import\node_modules\babel-core\lib\transformation\file\options\build-config-chain.js:96:16)  
    at buildConfigChain (Z:\git\eslint-plugin-import\node_modules\babel-core\lib\transformation\file\options\build-config-chain.js:61:13)
    at OptionManager.init (Z:\git\eslint-plugin-import\node_modules\babel-core\lib\transformation\file\options\option-manager.js:354:58)
    at compile (Z:\git\eslint-plugin-import\node_modules\babel-register\lib\node.js:103:45)
    at loader (Z:\git\eslint-plugin-import\node_modules\babel-register\lib\node.js:144:14) {
  at: 2,
  lineNumber: 1,
  columnNumber: 3
}

Node.js v18.11.0
node:events:491
      throw er; // Unhandled 'error' event
      ^

Error: spawn nyc ENOENT
    at notFoundError (Z:\git\eslint-plugin-import\node_modules\cross-spawn\lib\enoent.js:11:11)
    at verifyENOENT (Z:\git\eslint-plugin-import\node_modules\cross-spawn\lib\enoent.js:46:16)
    at cp.emit (Z:\git\eslint-plugin-import\node_modules\cross-spawn\lib\enoent.js:33:19)
    at ChildProcess._handle.onexit (node:internal/child_process:291:12)
Emitted 'error' event on ChildProcess instance at:
    at cp.emit (Z:\git\eslint-plugin-import\node_modules\cross-spawn\lib\enoent.js:36:37)
    at ChildProcess._handle.onexit (node:internal/child_process:291:12) {
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn nyc'
}

Node.js v18.11.0

Specs: windows 11 node 18.11.0 npm 9.4.0

[vcruzmj]

This (maybe) can be related:

https://github.com/detekt/detekt/discussions/7367#discussioncomment-9792560

[3flex]

There are a lot of thumbs ups on this... Not sure if there's a misunderstanding or if the compiler plugin is much more used than I thought!

detekt CLI and Gradle plugin support Kotlin 2. It's only the detekt compiler plugin that doesn't.

[nebffa]

@3flex at our company we use the detekt compiler plugin, so yes, having it supported on Kotlin 2.0 is necessary for us. Thanks for all your hard work :)

[nebffa]

@3flex I'm prepared to take a crack at this, however it will be easiest if detekt supports Kotlin 2.1.0 (or 2.1.0-Beta1 at least) as this allows us to target the latest compiler API which in turns makes it easy to draw inspiration from how the Kotlin team has done this with Kapt.

When I try to target Kotlin 2.1.0-Beta1 in the project, I get:

file:///Users/blucato/.gradle/caches/8.10.1/transforms/b6acbb9ae530cca2c86c1086a0b6ebfb/transformed/original/detekt-gradle-plugin-1.23.6.jar!/META-INF/detekt-gradle-plugin.kotlin_module: Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 2.1.0, expected version is 1.9.0.

[3flex]

Thanks @nebffa! Please track https://github.com/detekt/detekt/pull/7649 for Kotlin 2.1.0. Currently we cannot build with 2.1.0-Beta1.

Before uplifting compiler plugin support we need to confirm our future approach for adding proper and improved support for K2 front end. That discussion hasn't progressed far, see https://github.com/detekt/detekt/issues/7404. There's general consensus that we'll use the Kotlin Analysis API which is used by Kotlin plugin in IntelliJ and also KSP2.

Before proceeding I'd suggest we discuss possible approaches on #7404. If there's an easy way to add support for the compiler plugin while also remaining compatible with the Analysis API that's probably a path forward.

[detekt-ci]

This issue is stale because it has been open 90 days with no activity. Please comment or this will be closed in 7 days.

[3flex]

@detekt/maintainers

There are 41 👍 on this issue at time of writing. If we migrate to Kotlin Analysis API, we will need to close this as not planned.

In short:

• Platforms need to implement the Kotlin Analysis API platform interface for the Analysis API to work.
• There are only two platforms currently - Standalone API and IntelliJ Kotlin plugin. Of these, detekt-cli needs to use Standalone API.
• There are no plans to support additional platforms.

The only other options would be to continue to use compiler internals for analysis, likely using the Kotlin FIR (Frontend IR) compiler. This requires migration of a different kind and isn't supported for analysis use cases like the Analysis API is (some discussion here: https://github.com/detekt/detekt/issues/7404).

Or, we implement our own platform on top of the Kotlin compiler. I can't imagine how much effort and ongoing maintenance that would require.

There is more comprehensive information on the platform interface: https://github.com/JetBrains/kotlin/blob/v2.1.20-RC3/analysis/analysis-api-platform-interface/README.md

[cortinico]

There are 41 👍 on this issue at time of writing. If we migrate to Kotlin Analysis API, we will need to close this as not planned.

It seems like that going full on AA is the preferred route (also in terms of long term maintainability of our project - as it will expose us to less breaking changes).

I don't mind fully deprecating the detekt-compiler-plugin provided that we do have an alternative in place (a version of detekt fully working with AA) that serves as a replacement

[3flex]

I don't mind fully deprecating the detekt-compiler-plugin provided that we do have an alternative in place (a version of detekt fully working with AA) that serves as a replacement

I may not be understanding exactly what you mean - the benefit of the compiler plugin is that compilation happens once, and detekt can use the compiler output for semantic analysis, instead of detekt having to run its own compilation. There won't be any direct replacement for that capability.

The only front end will be detekt-cli (and the Gradle plugin which launches detekt-cli). That will use AA but cannot do analysis using compiler output.

Did you just mean that we keep it until we're fully migrated to AA, and drop it then?

[cortinico]

Sorry for super late reply @3flex

Did you just mean that we keep it until we're fully migrated to AA, and drop it then?

Yes I meant exactly that. Let's try to keep feature parity in some form

[dsvensson]

fyi, with Kotlin 2.2 out, using language level 1.9 now produces a deprecation warning which fails the build if using allWarningsAsErrors = true to prevent warnings slipping in.