feat: workspace folders

[doorgan]

This adds support for multiple projects within the server node, and starts a project node for each detected project within the workspace. The detection implemented here is just using the presence of a mix.exs file to assume it's a project root.

It also changes the manager node to use the name of the workspace folder instead of the name of the first project that starts distribution. The reason is that if you have projects a and b in the same root folder foo, and you start Expert on the root folder, then the manager node will be named after the first project node that is started. Running epmd -names shows this:

• project-a-entropy
• project-b-entropy
• manager-a-entropy

I htink having the manager be named manager-foo-entropy sounds more correct.

To test this branch you can clone this repo: https://github.com/doorgan/monorepo_test
Then check on files from both main and secondary that:

• Completions work
• Go to definition and workspace symbols work
• Code actions (like Refactorex refactors) work
• Instructing the LSP to reindex everything runs the indexer on all projects

Additionally you can also test that Lexical works on .exs or .ex files in a workspace without a mix.exs file.

It is worth noting that this should be tested with VS Code using the Lexical LSP extension and pointing it to an expert release using this branch, or some other editor (like emacs) that doesn't automatically start a new Expert server(ie something other than Neovim)

Closes #136

[mhanberg]

Are you able to add tests that validate adding and removing workspace folders?

Otherwise looks good, just change the PR title to say "feat: workspace folders"

[doorgan]

@mhanberg using GenLSP test helpers sometimes exunit will not terminate after running all tests(or sometimes it will run only a subset of the new tests), do you know if this may be related to the GenLSP helpers? Other tests that start project nodes like apps/expert/test/expert/engine_node_test.exs don't have this problem, so it seems unlikely the project node is what's causing this

[mhanberg]

@mhanberg using GenLSP test helpers sometimes exunit will not terminate after running all tests(or sometimes it will run only a subset of the new tests), do you know if this may be related to the GenLSP helpers? Other tests that start project nodes like apps/expert/test/expert/engine_node_test.exs don't have this problem, so it seems unlikely the project node is what's causing this

Not that I know of, but I'll pull it down and see what happens.

[mhanberg]

@mhanberg using GenLSP test helpers sometimes exunit will not terminate after running all tests(or sometimes it will run only a subset of the new tests), do you know if this may be related to the GenLSP helpers? Other tests that start project nodes like apps/expert/test/expert/engine_node_test.exs don't have this problem, so it seems unlikely the project node is what's causing this

Not that I know of, but I'll pull it down and see what happens.

Sorry about the wait, but I pulled this down. The tests seem to just run as normal, except for one test failing of a code error.

[Moosieus]

expert/apps/expert/lib/expert/configuration.ex

Lines 42 to 45 in 1a6a12e

	defp set(%__MODULE__{} = config) do
	# FIXME(mhanberg): I don't think this will work once we have workspace support
	:persistent_term.put(__MODULE__, config)
	end

This seemed foreboding and worthy of mention

[mhanberg]

@doorgan lets get this rebased and then address Cameron's comments, probably time to merge if it seems stable to you.

[doorgan]

This isn't stable anymore for me but I can't pinpoint why. I started getting these errors after a computer restart:

14:07:49.480 [warning] 'global' at :"expert-project-main-55714@127.0.0.1" failed to connect to :"expert-project-secondary-17485@127.0.0.1"
secondary: 
14:07:49.480 [warning] 'global' at :"expert-project-secondary-17485@127.0.0.1" failed to connect to :"expert-project-main-55714@127.0.0.1"


14:07:49.481 [warning] 'global' at node :"expert-project-secondary-17485@127.0.0.1" requested disconnect from node :"expert-project-main-55714@127.0.0.1" in order to prevent overlapping partitions

Then it starts an endless loop of trying to start either project node and nothing works anymore. It still works if I'm on a single root project, the problem happens when there's more than 1 project node.

Also FWIW I don't think we want project nodes connecting to each other.

[doorgan]

expert/apps/expert/lib/expert/configuration.ex

Lines 42 to 45 in 1a6a12e

	defp set(%__MODULE__{} = config) do
	# FIXME(mhanberg): I don't think this will work once we have workspace support
	:persistent_term.put(__MODULE__, config)
	end

This seemed foreboding and worthy of mention

This comment was stale, so I removed it

[mhanberg]

I'll take a look.

[doorgan]

I think I managed to fix the issue I was having. We were registering the nodes using the longname, but then trying to retrieve their ports using the shortname. Apparently it's not an issue with a single engine node because it's directly connected to the manager, but extra nodes makes :global try to fully connect the node mesh, then fails to find the port for the first engine node and kicks the second engine node from the mesh due to that failure to connect.