-
Notifications
You must be signed in to change notification settings - Fork 3
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
Initial prototype implementation #8
base: main
Are you sure you want to change the base?
Conversation
b06d804
to
9b0ecae
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.
Code is nice 👍, now will check tests and do some testing
@@ -0,0 +1,34 @@ | |||
{ |
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 note: Some versions seems older, seen by npm outdated
, and npm install
shows some 'moderate severity vulnerability' but build becomes OK once I run npm update
}; | ||
} | ||
|
||
readFile(uri: vscode.Uri): Uint8Array { |
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.
unused 'uri' but can be replaced with _uri
, same for stat()
deps: { | ||
interopDefault: true | ||
}, | ||
include: ['packages/**/test/**/*.test.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.
Can we set some basic coverageThreshold in vitest config? Build automatically fails if coverage drops down, simple and helpful during dev.
Like in Jest e.g.:
thresholds: {
lines: 80,
functions: 80,
branches: 80,
statements: 80
}
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 would strongly advise against that because it won't help with the quality and will create a number of undesired side effects.
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 common practice. Side effect only happens in code change not in test, this is just a test coverage measurement. Same measures tuned in sonar or Jenkins upon project.
LGTM, works the same way in IntelliJ IDEA |
Please, add |
packages/extension/.vscodeignore
Outdated
.vscode/** | ||
.vscode-test/** | ||
src/** |
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.
How about explicitly only including what is needed? package.json
and README.md
are included automatically.
.vscode/** | |
.vscode-test/** | |
src/** | |
# Ignore everything | |
* | |
**/* | |
../**/* # when `vsce` run with `--no-dependencies` this is not needed | |
../../**/* # when `vsce` run with `--no-dependencies` this is not needed | |
# Add what we actually want | |
!out/extension/main.cjs | |
!out/extension/main.cjs.map | |
!language-configuration.json | |
!syntaxes/pli.merged.json |
Can we replace |
|
8aa2a54
to
a6e1b12
Compare
packages/extension/README.md
Outdated
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.
Let's leave an empty line - MD047
packages/language/README.md
Outdated
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.
New EOL character MD047
From the repo perspective, it would be better to separate the actual solution between different folders. The implementation is intended to be supported both in VS Code and IntelliJ IDEA. Can I ask the team to bring all the VS Code related things into the "vscode-extension" folder? So that it would be a clear separation between the VS Code and IntelliJ IDEA parts in the future |
It is a good idea, I agree. |
@KUGDev I agree, that's why all the VS Code related parts already are part of the |
@msujew ok I see. Then the IntelliJ IDEA related stuff will go into the "packages" folder as well. Will the "extension" folder remain with the same name? Cause if we add the "plugin" folder, it would mean that we are going to provide IntelliJ IDEA plugin only. I guess, the "intellij-plugin" naming would be more appropriate, and to stay consistent, it would mean that for the VSCode extension the folder name "vscode-extension" would be more appropriate as well |
cfe3f94
to
d5bf1a6
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.
💯
1f0d1c2
to
cfcd5bf
Compare
}, | ||
"volta": { | ||
"node": "18.20.3", | ||
"npm": "10.7.0" |
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.
What about pnpm, can Volta manage it as well?
Also how about having an .nvmrc
file? I think it is more common than Volta. In addition to nvm
it is also supported by fnm
which I have been successfully using and very happy with for years.
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 believe our yeoman generator automatically adds the volta
entry. I can add a .nvmrc
file instead 👍
Co-authored-by: Benjamin Wilson <[email protected]> Co-authored-by: Markus Rudolph <[email protected]> Signed-off-by: Mark Sujew <[email protected]>
cfcd5bf
to
6b5d434
Compare
This is an initial implementation of the PL/I language server using Langium. It supports most (as far as we can tell) of the base language. Missing prominent features: