-
Notifications
You must be signed in to change notification settings - Fork 67
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
generator-langium: Transform generated project to npm workspace #1520
base: main
Are you sure you want to change the base?
Conversation
@msujew @Yokozuna59 the generated workspace project builds again. Now, I need to fix the open points above ⬆️ |
ea748fa
to
16211b6
Compare
@msujew @Yokozuna59 this is now ready for review. The only thing left is from the list is removing the need for |
For me workspaces were hard to work with in the beginning, because I was switching to the packages folders to run |
Very likely 🙂 We need to update it once this is merged. |
The generated project is the blueprint. 👍 It features all facets: TS with specific test configs, VSCode eslint compatibility (root tsconfig.json per package), workspace eslint check, global build and top-level scripts that directly execute package scripts. |
All points are resolved. I also fix an issue with the web example. I broke the configuration during this update. It is working again. |
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'm not sure if I should review this PR or not, but since it was mentioned, I reviewed it.
The below review is just comments or questions regarding this approach, which could be ignored if you don't feel they are correct.
One more thing, since you updated the out
directory here:
langium/packages/generator-langium/templates/packages/language/langium-config.json
Line 14 in 8931941
"out": "src/generated" |
I think you may need to update the .gitignore.txt
:
src/language/generated/ |
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 think this file need to modified since some files are moved to different directories.
I would recommend to move the file to the root directory then reference the files from there.
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.
Thank you, good point. I overlooked that.
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 have added a TODO for this in PR description. ⬆️
packages/generator-langium/templates/packages/language/test/linking/linking.test.ts
Outdated
Show resolved
Hide resolved
packages/generator-langium/templates/packages/cli/src/cli-util.ts
Outdated
Show resolved
Hide resolved
packages/generator-langium/templates/packages/extension/.vscodeignore
Outdated
Show resolved
Hide resolved
7c811fc
to
94ab736
Compare
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.
@kaisalmen I'm not sure if these comments should be resolved yet:
- generator-langium: Transform generated project to npm workspace #1520 (comment)
- generator-langium: Transform generated project to npm workspace #1520 (comment)
See below.
packages/generator-langium/templates/packages/language/test/parsing.test.ts
Outdated
Show resolved
Hide resolved
packages/generator-langium/templates/packages/language/test/linking.test.ts
Outdated
Show resolved
Hide resolved
packages/generator-langium/templates/packages/web/vite.config.ts
Outdated
Show resolved
Hide resolved
@Yokozuna59 thank you for the review. I still need to implement the two bigger points (added to the description) and then I am done. Any further enhancements should go to a next PR, because this one is already quite large, but there was no way around. |
2bf7da8
to
7ba0b13
Compare
@Yokozuna59 and @msujew all TODOs are done. We need to update tutorials and docs on the website as well. This change has some impact. |
7ba0b13
to
84a13c7
Compare
I rebased the branch after Langium 3.1.0 release to resolve the conflicts. |
40576e4
to
bbd095b
Compare
@msujew I just updated to the latest wrapper version. Do you have time to review it this week? |
@@ -0,0 +1,45 @@ | |||
{ | |||
"name": "<%= extension-name %>-language", |
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.
Issue: This package name is built by using the specified extension-name
. However, all references to this package (i.e. tests, vscode extension, etc.) use the specified language-id
. If I call my extension abc
and my language cba
:
- The language package will be called
abc-language
. - All imports for that language will attempt to import
cba-language
.
This obviously yields errors on build. Both should use the same ID.
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.
@msujew then language-id
is the better choice. extension-name
is only useful for the VSCode extension. Do you agree?
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 have changed it like suggested for now. ⬇️
export * from './generated/ast.js'; | ||
export * from './generated/grammar.js'; | ||
export * from './generated/module.js'; | ||
export { default as monarchSyntax } from './syntaxes/<%= language-id %>.monarch.js'; |
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.
Question: We should only conditionally generate this export - if the web
option is selected.
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.
Yes, true, I will adapt this.
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 was a bit more work, because I needed to change the workflow, but it looks good now, IMO.
@@ -11,5 +11,5 @@ | |||
"out": "src/syntaxes/<%= language-id %>.monarch.ts" |
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.
Suggestion: As mentioned above, we should try to make this conditional.
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.
Yes, true, I will adapt this.
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.
Done, see above.
"textMate": { | ||
"out": "syntaxes/<%= language-id %>.tmLanguage.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.
Suggestion: The textmate grammar is generated into a folder in the language
package. However, it is referenced the package.json of the VS Code extension as if it were located inside of the extension
package. Unless the adopter changes the generated path or copies the file manually, they don't get syntax highlighting in VS Code.
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 added a build prepare step in both web and extension that copies the file over. ⬇️
packages/generator-langium/templates/packages/extension/langium-quickstart.md
Outdated
Show resolved
Hide resolved
packages/generator-langium/templates/packages/extension/langium-quickstart.md
Outdated
Show resolved
Hide resolved
a59cf4b
to
3c0b81d
Compare
@msujew rework is complete. Im have not closed some of the discussions, because you should check if you agree with my solutions. |
@kaisalmen I created a project from this branch and it seems there is an issue with the generated CLI. I think the following paths inside
At least that's what I edited manually in my project for it to work |
@aabounegm Thank you very much! Many things changed, it is easy to overlook things. I will push an update. |
any updates on this? |
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 just noticed another issue while packaging my extension. Also, npm run lint
from root is broken, the path passed to the command should be ./packages/*/src
instead of just src
.
packages/generator-langium/templates/packages/extension/package.json
Outdated
Show resolved
Hide resolved
And one more thing: it seems that
I personally opted for the first option in my project with a comment linking to the issue. And on a somewhat related note (also publishing), I would suggest adding a |
We used solution 2 in our own extension, too: langium/packages/langium-vscode/package.json Lines 84 to 86 in 3b007c2
|
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 got this thought while exploring how a JetBrains plugin would look like, and realized I'm copying main.cjs
from extension/out/language
rather than from language/out
directly.
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.
Is there a reason this file resides under the extension
folder and not under language
?
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 assume chase it’s specific to the use case as packages/generator-langium/templates/packages/web/src/main-browser.ts is
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.
Except that this one runs a language server regardless of the context as long as Node is available. The browser is the exception because it does not have Node.js or access to the file system.
For example, I installed LSP4IJ in WebStorm and pointed it to this file (node /.../extension/out/language/main.cjs --stdio
) and it ran perfectly
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.
The philosophy behind this change is that the language
package is designed to be used like a runtime independent library. For example, the CLI package makes use of that as well, without running a whole language server.
Then, every consumer can make use of the library as they like. Some build a VS Code extension, others a web project or a CLI. In my mind all of these packages should provide their own entry point. I think that's reasonable as a default for the generated project.
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.
Got it. I don't see why it can't be both a library and still expose an endpoint, but it's not a big deal, it's easy to duplicate that file. The only (minor) issue in this case is having to make the JetBrains plugin a JavaScript module as well (as in, it will have both package.json
and the gradle stuff) to compile the JS file (with the exact same content as extension/src/language/main.ts
) instead of just copying it from language/out/main.cjs
(for example).
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.
For those cases where a build artifact is required by multiple consumers, we usually just copy it around via some build task/script using shx
or gulp
. I think the generated build is fine as it is. It's not like we prevent adopters from changing how their build works after yeoman has done its job.
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 see, but the only problem here could be in the (admittedly rare) occasion that someone does not generate a VS Code extension, and opts only for JetBrains plugin (for example, once that is ready).
It's not a big deal, I just need to decide whether to copy that language/main.ts
to the new submodule and make it an npm package as well, or just depend on extension
(VS Code) always existing.
It's not like we prevent adopters from changing how their build works after yeoman has done its job
Fair enough. Feel free to resolve this comment.
- 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
42e3a41
to
cff11ba
Compare
@aabounegm thank you for those additional findings/comments. Regarding vsce I selected option 2, modified the gitignore and fixed the prebublish/lint |
TODO:
generator-langium
unit teststsconfig.build.json
needs to be dynamically created. Sources not contained should not be included as it leads to build failures otherwise.http-server
Fixes #1495
TODO: from review:
build:clean
to all packages