reduce number of top-level files

[bollwyvl]

References

• blocks Start sphinx docs #177 https://github.com/krassowski/jupyterlab-lsp/pull/177#discussion_r370933583

Code changes

Moves a lot of things around. There is a hard reference to LANGSERVERS.md in the source: we should probably just inline that or something... or point to readthedocs when we do that.

User-facing changes

The repo is a tad cleaner on first blush:

• fits on a full screen, meh
  • 

Backwards-incompatible changes

shouldn't create any issues on PRs...

Chores

• linted
• tested
• documented
• changelog entry

[bollwyvl]

To really go after it, we need all the meta junk from python:

• setup.{cfg,py}
• MANIFEST.in
  and js:
• package.json
• lerna.json
• yarn.lock
• .prettierignore
  .. in separate dirs altogether. I'm happy to do that (once I get at least this working), but that will start to impact the usability, i fear.

[bollwyvl]

Another thought: if the DX is indeed getting onerous, we can fix it Once And For All and introduce a top-level automation tool, and indeed, that might even be worthwhile, especially as we increase the number of built artifacts (#177, #163). If we want to go that way, this PR is a fine place to do it: i find it onerous to incrementally change automation if we can get consensus vision of where we want to go.

make would be great, but in 2020, it's still hard to reliably get a working windows toolchain, same goes for node-based stuff, so i'd favor doit. Others i've tried include pants and scons: again, they are rather heavy opinions.

Positing doit (but likely very similar for other tools): this would replace scripts with a single, top-level dodo.py, and after a pip install -e . (and getting node somehow), you'd type doit <thing>. Running without any args would basically run the entire azure pipeline locally, which is actually fantastic for reviewing PRs and CI. If you do a touch of extra work, it can do the make-like thing: e.g. if you change the ts, but don't touch the python, it won't even run the python unit tests, but would run the acceptance tests (after first rebuilding your lab so you don't get the thinger blocked by dialog warning).

Anyhow, food for thought...

[bollwyvl]

Well, I guess I'll take it passing the first time. No doubt i missed some stuff in the markdown links, but that will be tested aggressively on #177, so less inclined to worry about it at this point...

[krassowski]

One lazy option would be to point to a version-specific commit and have a link to master in the document itself (something like "there might be an updated version of this document >click here<".)