-
Notifications
You must be signed in to change notification settings - Fork 66
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
Intellij template #1618
Conversation
- Align template structure with target structure - Integrate a global tsconfig.build.json - Unify how build and compile is done - Make cli, web and extension compile again
- Updated relevant dependencies and aligned version in the repo
…eed for http-server
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing here
from("../extension/out/language") { | ||
include("main.cjs") |
There was a problem hiding this comment.
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.
from("../extension") { | ||
include("package.json") | ||
include("syntaxes/*.tmLanguage.json") | ||
include("language-configuration.json") |
There was a problem hiding this comment.
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', |
There was a problem hiding this comment.
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?
There was a problem hiding this 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?
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). 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). |
42e3a41
to
cff11ba
Compare
@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). |
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 😁. |
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. |
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.
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. |
I finally made a template repo with the contents of this PR so I can finally close it: aabounegm/langium-intellij-template |
@aabounegm that repo is archived, is that on purpose? |
@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. |
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 😁.