Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intellij template #1618

Conversation

aabounegm
Copy link
Member

This PR adds the option to generate a plugin for IntelliJ-based IDEs (including WebStorm, Android Studio, and many others listed here). It is largely based on JetBrains/intellij-platform-plugin-template.
It depends on the LSP4IJ community plugin by RedHat to add LSP support to non-paid versions of the IDEs.

While LSP4IJ currently supports IntelliJ starting with version 2023.2, the plugin generated by this template requires at least 2024.1 for TextMate highlighting support. Ideally, we should instead generate IntelliJ's own syntax highlighting factory, but I don't think I will have the time to do that anytime soon since TextMate fits my needs (I already had a comprehensive TextMate grammar defined long ago and wanted to reuse it).

I should also note that I am totally not an expert in Java/Kotlin, so the code there may not be the best Kotlin code, but it does the job and I was guided by IntelliJ IDEA 😁.

Copy link
Member Author

@aabounegm aabounegm left a comment

Choose a reason for hiding this comment

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

Just some comments and questions

@@ -397,19 +438,23 @@ export * from './generated/module.js';
return this.destinationPath(USER_DIR, this.answers.extensionName, ...path);
}

_replaceTemplateWords(fileExtensionGlob: string, languageName: string, languageId: string, content: string | Buffer): string {
_replaceTemplateWords(fileExtensionGlob: string, fileExtensionDefault: string, fileExtensionsSemi: string, languageName: string, languageId: string, content: string | Buffer): string {
Copy link
Member Author

Choose a reason for hiding this comment

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

I had a strong urge to replace this with a single object parameter to look better (like named parameters), but I didn't want to modify existing code as much as possible.

.replace(LANGUAGE_NAME, languageName)
.replace(LANGUAGE_ID, languageId)
.replace(NEWLINES, EOL);
}

_replaceTemplateNames(languageId: string, path: string): string {
return path.replace(LANGUAGE_PATH_ID, languageId);
_replaceTemplateNames(languageId: string, languageName: string, path: string): string {
Copy link
Member Author

Choose a reason for hiding this comment

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

Same thing here

Comment on lines +132 to +133
from("../extension/out/language") {
include("main.cjs")
Copy link
Member Author

Choose a reason for hiding this comment

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

This here is the main reason this package depends on the VS Code extension. If this dependence is undesirable, we can add a minimal JS package to this (intellij-plugin) subpackage instead.
For my purposes, I need a VS Code extension anyway, and I assumed it would be rare for someone to need only IntelliJ, so I disabled the IntelliJ prompt if VS Code wasn't included.

Comment on lines +138 to +141
from("../extension") {
include("package.json")
include("syntaxes/*.tmLanguage.json")
include("language-configuration.json")
Copy link
Member Author

Choose a reason for hiding this comment

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

This is the other reason it depends on the VS Code extension. Technically, it should be easy to copy the TM syntax from language directly, but I'm not sure about language-configuration.json (actually, I'm not even sure if IntelliJ needs/understands it, I forgot to test for that 😅)

'Your language can be run inside of a JetBrains IntelliJ-based IDE plugin.'
),
message: 'Include IntelliJ integration?',
default: 'yes',
Copy link
Member Author

Choose a reason for hiding this comment

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

Should I keep this default as yes or does it make more sense to not include it by default?

Copy link
Member

@msujew msujew left a comment

Choose a reason for hiding this comment

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

Hey @aabounegm, thanks for looking into this. We've had discussions around this in the past (see #999 and eclipse-langium/langium-website#243) and I believe this is better served as a guide on our website rather than included in the yeoman generator.

I'm kind of torn on this issue right now. While this increases our reach beyond the VS Code ecosystem in an easy-to-use way, it's also quite a bit of maintenance effort and we don't have anyone (in the active Langium committers) working on IntelliJ based plugins right now at all. Since the langium-specific part of this is rather minimal (most of this PR is IntelliJ boilerplate), I would rather expect a yeoman generator or similar from the RedHat people for this, instead of us offering something.

As mentioned, I'd rather see this as a page on our website, mostly just linking to the developer guide for LSP4IJ with some langium-specific additions on top. @spoenemann @kaisalmen your thoughts on this?

@aabounegm
Copy link
Member Author

Hi @msujew, I understand your point, especially about the maintenance, but after spending several days trying to get everything right for an IntelliJ plugin, I thought it would be helpful to others if I add it to the template, especially that the documentation about it is not so great and I had to search through multiple forums and deal with some bugs that had no logs and so on, so I just wanted to share it to save other people's time (especially those not proficient in Java/Kotlin, like me).
About the Langium-specific part being minimal, isn't that also the case with the web package, for example?

We could technically make it into a guide, but it will mostly consist of "add this file with that content" blocks, so I don't see why maintaining the guide would be any less effort than maintaining the template (which should hopefully not require that much maintenance anyway).

@kaisalmen kaisalmen force-pushed the kaisalmen/issue-1495 branch from 42e3a41 to cff11ba Compare August 8, 2024 13:26
@kaisalmen
Copy link
Contributor

@aabounegm and @msujew maybe after #1520 is merged, we could think about making the generator extendable. If the npm package exposes callable functions/extendable methods to process an additional package, then any further code extending the generator must not be contained here. Then even for the web package could be moved to an external location. Let me think about that, but only after #1520 is merged (it is already too big).

@msujew msujew added the yeoman Yeoman generator related issue label Aug 8, 2024
@aabounegm
Copy link
Member Author

Yes, I definitely agree that this one should only be considered after the main one is merged, I just wanted to get it out of the way before I forget the context of how I made the plugin 😁.
Perhaps it would be better if I convert it to a draft PR for now.

@aabounegm aabounegm marked this pull request as draft August 9, 2024 21:25
@spoenemann
Copy link
Contributor

Hey @aabounegm, thanks for looking into this. We've had discussions around this in the past (see #999 and eclipse-langium/langium-website#243) and I believe this is better served as a guide on our website rather than included in the yeoman generator.
I'm kind of torn on this issue right now. While this increases our reach beyond the VS Code ecosystem in an easy-to-use way, it's also quite a bit of maintenance effort and we don't have anyone (in the active Langium committers) working on IntelliJ based plugins right now at all. Since the langium-specific part of this is rather minimal (most of this PR is IntelliJ boilerplate), I would rather expect a yeoman generator or similar from the RedHat people for this, instead of us offering something.
As mentioned, I'd rather see this as a page on our website, mostly just linking to the developer guide for LSP4IJ with some langium-specific additions on top. @spoenemann @kaisalmen your thoughts on this?

I agree. The increased maintenance effort would become a problem with time.

What's the normal way to create projects in IntelliJ? Eclipse has a concept of "Project Wizards" that do the same as Yeoman, but with a GUI.

@aabounegm
Copy link
Member Author

I agree. The increased maintenance effort would become a problem with time.

Alright, if you prefer, I can simply make a template repo on my personal account so it doesn't become a maintenance burden on you, because I believe a template would be much more useful than a guide. Perhaps a dedicated README covering what the template does (and how it changed from the original IntelliJ plugin template) could serve as a guide for how to keep it up to date as well.

What's the normal way to create projects in IntelliJ?

I'm not sure, to be frank. I'm not an IntelliJ user myself, but some of the users of the language I'm working on are. This particular project was based on JetBrains/intellij-platform-plugin-template.

@aabounegm aabounegm closed this by deleting the head repository Oct 14, 2024
@aabounegm
Copy link
Member Author

I finally made a template repo with the contents of this PR so I can finally close it: aabounegm/langium-intellij-template

@spoenemann
Copy link
Contributor

@aabounegm that repo is archived, is that on purpose?

@aabounegm
Copy link
Member Author

@spoenemann yeah, it seemed to me that the base PR (#1520) kinda stalled, and I don't think I intend to maintain the IntelliJ any further, so I archived to avoid annoying dependabot alerts. If there is a good enough reason (at least some demand), I can unarchive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
yeoman Yeoman generator related issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants