Integrate IntelliJ plugin into pnpm 🚀

[jamthief]

Rehome IntelliJ extension in packages/intellij-extension, and integrate into pnpm 🚀

Also some misc fixups:

• Don't define "until" IntelliJ version support (open ended for now)
• Add Cypher language description
• Add Cypher file template description

[changeset-bot]

⚠️ No Changeset found

Latest commit: 5fce706

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[jamthief]

The E2E check looks flaky, but I can't find a way to re-run it. Maybe I'm missing the permission?

[ncordon]

I'm not sure why, I get this when I do npm run build:

2025-04-07 13:17:45,255 [   9534]   WARN - #c.i.k.a.KubernetesApiProvider - Cannot run program "kubectl": error=2, No such file or directory
com.intellij.execution.process.ProcessNotCreatedException: Cannot run program "kubectl": error=2, No such file or directory
        at com.intellij.execution.configurations.GeneralCommandLine.createProcess(GeneralCommandLine.java:384)
        at com.intellij.execution.process.OSProcessHandler.startProcess(OSProcessHandler.java:85)

What's Kubernetes used in the build exactly? Is it that sandbox we've added? It works after installing kubectl but not sure why it wasn't before.

In main executing the build of the plugin was working fine for me.

[ncordon]

I'd prefer to have this as:

if [[ \"$BUILD_INTELLIJ\" == \"true\" ]]; then ./gradlew -q buildPlugin; else echo 'Skipping Intellij build, set BUILD_INTELLIJ=true if that is not the desired behaviour'; fi

So this does not get executed for the people that work currently on the repo unless they specifically have that env variable set. The reason is we have 4 / 5 people that contribute regularly right now from the company, some of them using OSX, some using Windows, so I don't want to force them to install Kubernetes locally.

[ncordon]

@anderson4j can you try this works for you if we gated the code?

[anderson4j]

Yep, this skips and regular build works!

[jamthief]

@ncordon I think I get your gist - although it needs a single equals sign to work: [[ \"$BUILD_INTELLIJ\" = \"true\" ]] - unfortunately though, this gets cached by turbo. So running it with a different value will just do the same thing over and over, even if you change the environment variable. I guess we could make a special build target instead?

However, in principle, I want to argue against doing this anyway. My reasoning is as follows:

• The VS code extension and the IntelliJ plugin are both at identical positions in the build hierarchy: they are dependent on the language server build, and they are leaf node outputs. Running a generalised build at the top level should be the equivalent of something like make all; it should attempt to build everything by default.
• If a developer has a workflow involving one or the other plugin, they should use the specialised build target
• If running the whole build doesn't work in CI, this PR is incomplete
• If we don't attempt to build it regularly, and fail the build when it also fails, then we won't know when we've broken it, and the plugin will become stale

[jamthief]

@ncordon

I'm not sure why, I get this when I do npm run build:

2025-04-07 13:17:45,255 [   9534]   WARN - #c.i.k.a.KubernetesApiProvider - Cannot run program "kubectl": error=2, No such file or directory
com.intellij.execution.process.ProcessNotCreatedException: Cannot run program "kubectl": error=2, No such file or directory
        at com.intellij.execution.configurations.GeneralCommandLine.createProcess(GeneralCommandLine.java:384)
        at com.intellij.execution.process.OSProcessHandler.startProcess(OSProcessHandler.java:85)

What's Kubernetes used in the build exactly? Is it that sandbox we've added? It works after installing kubectl but not sure why it wasn't before.

In main executing the build of the plugin was working fine for me.

It's pretty gross, but also harmless. The build still passes. I see it too when I forcibly rename the kubectl binary to something else. Did you have kubectl installed before? I wonder if it thinks you have kubernetes support and so tries to run it.