Tweak project root heuristics #29
Conversation
|
@BlueHotDog would you be willing to set some tests up for this, before I take a look at this? |
|
Sure! i think it would be great to add contribution guidelines. how do i run tests? what tests should i write? do we have code-coverage? |
|
@IwanKaramazow hey, could you please give me a quick rundown on how tests are structured currently and what i should run to satisfy the project requirements(happy to add them myself to the readme) |
|
@BlueHotDog Sorry for the late reply, turns out there are no tests in place yet. Will have to take care of that first |
|
NP, maybe we can manually test it and merge it meanwhile? we can't adopt it right now since we use a monorepo |
|
Hi guys, whats the ETA on this? |
|
@BlueHotDog taking a look at this now, can you rebase on master? |
|
Also does this work locally on your setup? Server doesn't seem to start with this branch, might be something on my computer? |
The project root means "this is a folder containing node_modules/bs-platform/{platform}/bsc.exe".
This path needs to be correct because it drives the formatter.
The previous heuristics seemed to fail in the case users where using yarn workspaces.
Yarn workspaces seem to have the following layout:
```
/root
/node_modules
- package.json
- yarn.lock
/folder1
/node_modules
- package.json
- bsconfig.json
```
The compiler seems to be located in the `node_modules` under the root and not in the `node_modules` of `folder1`.
By searching for `bscPartialPath` instead of the nearest `bsconfig.json`,
we can correctly determine the root.
the "build root" represents the nearest directory containing a "bsconfig.json" file. "bsconfig.json" can be used to locate the nearest build artefacts and .compiler.log for diagnostics.
BlueHotDog
force-pushed
the
tweak-project-root-heuristics
branch
from
16d68b7 to
ce51fac
Compare
|
@IwanKaramazow well, this was stale so a bunch of breaking changes merged to master. |
|
@BlueHotDog I formalised the different cases in #51 |
|
hey guys, any way i can help with this? really want to contribute to this project..(and also start actually using the new syntax) |
|
Hey BlueHotDog! We'd like to avoid early compartmentalization because the editor's various use-cases are still not well defined, so the compartmentalization is more harmful than beneficial. For example, this would have made #59 and subsequent cleanups harder. Thankfully that one was merged first, which obsoletes most of this PR's cleanup actually (it's a good thing). Independent of this PR, one thing is that we don't want to have a notion of an editor "project". This is a concept that doesn't fit well into many's workflow (e.g. the moment you open a new tab on a file that isn't part of a project) and certainly goes against most other LSP-enabled editors' usages (though we also try to only use LSP for vscode and vim, due to LSP being not ideal in general). Thanks for the effort though =) |
|
Though we should write down this latter part somewhere more prominent. |
|
thanks for the elaborate response @chenglou . two questions:
|
|
Yeah 1.0.4 supports monorepo formatting now |
This is based off the work of: #16
I wanted to suggest a couple of conventions and organization practices as this project is expected to grow:
The benefit of having things like Project/File/ and various other Domain Contextes is that they're by definition easier to test.
What do you guys think?
If you like it, i would love to proceed and organize Server.ts