The plugin should update the SLua definition files even if it never connects to a viewer

[tapple]

People's first desire when using this plugin is just to typecheck their slua code. This should just work, out of the box, without requiring any of these steps:

• Downloading a project viewer
• Launching a viewer
• Changing their editor binding in the viewer
• Teleporting to a lua sim
• editing a script in the viewer
• editing a prim in the viewer

They can set that up later, and just use copy/paste for as long as they want, as long as the plugin just lets them typecheck their damn code.

When a workspace opens, and the plugin is enabled, it should compare its files against the latest build at https://github.com/secondlife/lsl-definitions/releases

The plugin should probably keep 2 parallel versions of the definitions files, as they use incompatable version numbers, even if the files themselves are identical:

• a copy from the last connected simulator (version number is a UUID)
• a tagged release build (version number is semantic)

[tapple]

here's the github api url to fetch. it doesn't appear to need an api key or anything:

• https://api.github.com/repos/secondlife/lsl-definitions/releases/latest

[WolfGangS]

I would suggest including a copy of the latest files at time of build in the plugin itself, as a further fallback

Right now the project still has the data files for the old method of generating the syntax etc, I believe they should be redundant going forward, so adding a build step to pull https://github.com/secondlife/lsl-definitions and bundle those in, instead would be good.

[Rider-Linden]

As part of the build the plug in should just pull the latest versions of the language files.
The big win is I can remove the generators from the plugin.

[tapple]

as of release 1.0.5, the builtin definitions are never added to the configurations for luau-lsp and selene. I don't know if this is

1. a bug (unintended side-effect of something else
2. a workaround (the builtin d.luau file has syntax errors in the last couple versions of luau-lsp due to the obsolete define class syntax)
3. a feature (intended)

This gave the initial reporter on discord the impression that 1.0.4 was broken due to syntax errors in the definitions, and 1.0.5 was broken due to absent definitions

[tapple]

I think bundling at build time vs downloading at runtime will make very little real difference once luau leaves beta and updates slow way down. And, build time is all 3 of:

1. more-reliable
2. lower-bandwidth
3. easier to implement

I'd consider this issue closed if build-time, run-time, or both are implemented, as either one solves the use case of "I just want to install an extension and have my code typechecked like every other vscode extension"

And, once people's preferred viewer has luau, there will be less friction to using the connect to viewer part of the plugin also, and getting updates that way, so the "update from github" alternative will be less necessary. And they can still do that manually if they really want to (like I do). The setting I added for that less-recommended workflow #62 isn't going anywhere

[WolfGangS]

I think, build time + caching the ones it gets from sl?

I find myself a little hesitant in my own project to implement features that rely on any form of github api, as those have come and gone with time sometimes, though the releases on has been pretty stable.

If having the plugin have an "UP TO DATE" included version is important could have a monthly rebuild, that auto increments minor version? Or a date based versioning system.

[tapple]

I doubt the definitions will even change monthly, once we release. maybe the comment strings could. The vscode comment strings are still new enough that I haven't yet started relying on them over the wiki. will see how my habits change going forward, and how important those actually are