Plugin dev ux improvements

[boatbomber]

It's pretty annoying to work on the plugin because the Luau LSP doesn't support nested project files (ie: plugin/...json) & the handy scripts for common actions are not uniform and undocumented. Also, the unit tests are flaky (at least on my machine) cuz it doesn't use WaitForChild on ReplicatedStorage descendants.

[Dekkonot]

considered naming the root-level project file more descriptively, like plugin.project.json, but Luau LSP only supports one project name that it searches for- if I set it to plugin.project.json, then every other project I work on will stop having LSP support

You can set a setting for only the local workspace in VSCode, assuming you use that. If you don't, then idk.

[boatbomber]

Oh yeah I could add a .vscode folder to the repo so everyone using vscode gets LSP support, totally forgot I could do that lol

[kennethloeffler]

While you're at it, could you do some stuff for me? 😅

I use Emacs with eglot-luau, and for project-specific configuration I need a file called .dir-locals.el. To match your VS Code settings here, I'd need a .dir-locals.el under the project root containing the following:

((nil . ((eglot-luau-rojo-project-path . "plugin.project.json")
         (eglot-luau-rojo-sourcemap-enabled . 't))))

Since I and my Emacs represent the vast minority of those that will ever interact with this project, I don't necessarily want this file tracked in source control, and would be totally fine with just adding .dir-locals.el to .gitignore; but, I'm not necessarily against it either...

[boatbomber]

While you're at it, could you do some stuff for me? 😅

I use Emacs with eglot-luau, and for project-specific configuration I need a file called .dir-locals.el.

Added :)

[kennethloeffler]

It may be cumbersome to have to maintain two project files: one at plugin/default.project.json and plugin.project.json in the project root. It has me wondering if there's a way to cajole VS Code into starting the language server with a specific subdirectory as the CWD (Emacs can do this 🕶️)!

If not, then I'm okay with it for now, and if it requires additional support from the Luau Language Server, then we should see to contribute improvements there. We might also consider removing plugin/default.project.json and relying on the project at the project root instead, but we'll have to make sure that we change anything that relies on plugin/default.project.json.

I read the diff incorrectly, lol - we still only have one project file. The bit about cajoling VS Code to start the language server in a specific subdir still stands though

[kennethloeffler]

I think we just need to change the "Build Plugin" step in our GA release workflow to use the new project file, and this should be good to go:

rojo/.github/workflows/release.yml

Lines 33 to 34 in 8c33100

	- name: Build Plugin
	run: rojo build plugin --output Rojo.rbxm

[kennethloeffler]

So, somewhat annoyingly, we also have to modify the build script to have a plugin subfolder for the plugin project snapshot, otherwise rojo plugin install is broken.