v1.70.4L - Resources Get Doc Strings

All things considered, this is a pretty small update. Most of this is just a handful of bug fixes and internal restructuring to make things more legible. However, that's not to say that there is no new things in this update. For starters, I gifted you a brand new bug I found out about literally minutes after waiting over a half an hour for the builds to finish compiling! Wow, isn't that great?! The bug itself is simple: As I was trying to research the arguments game.World.Pairs's relation string to add them to the LSP, I absent-mindedly gave them the component group and ended up committing it. But since you can't exactly do that with pre-compiled binaries, you'll have to fix it yourself. The easy way is this:

"platform": {
  "luduvo": {
    "resources": {
      "completion": {
        "disabledApis": [
          "game.World.Pair",
          "World.Pair"
        ]
      }
    }
  }
}

The harder way is this:

"platform": {
  "luduvo": {
    "resources": {
      "groups": {
        "relation": {
          "dataType": "string",
          "sources": ["pair relations"]
       },
      "sources": {
        "pair relations": {
          "provider": "static",
            "values": [
                {
                  "name": "Tag",
                  "documentation": "Relate a tag of the name 'target'. Target should be a string",
                },
                {
                  "name": "ChildOf",
                  "documentation": "Relate a parent of the instance 'target' to whatever is given this pair. The target should be an instance, and does not automatically reparent anything. \n\nPrimarily use this for Queries and `:HasComponent()` checks, as the engine will automatically add this pair for you where appropriate.",
                },
                {
                  "name": "WornBy",
                  "documentation": "Relate an accessory to the character 'target'. Target should be an instance, and doesn't automatically equip any accessories. \n\nPrimarily use this for Queries and `:HasComponent()` checks, as the engine will automatically add this for you where appropriate.",
                },
            ],
          },
        },
      "bindings": [
        {
          "symbol": "game.World.Pair",
          "parameter": "relation",
          "kind": "relation"
        },
        {
          "symbol": "World.Pair",
          "parameter": "relation",
          "kind": "relation"
        },
      ]
    }
  }
}

But it'll give you much better rewards. Because now resources support descriptions in your autocomplete! It looks like this:

So at least there's that. Honestly, it wasn't even that hard to add —the restructure was a lot more time-consuming than this turned out to be. Alongside this comes improvements to the component builtin resource, as now most of them have proper comments! I sourced them directly from Luduvo's actual internals, so it should be accurate (for the ones that have it). Custom components also are making their way to the autocorrect, so if you ever need to add a tool or something, you now can! When "custom" hardcoded components stop being hardcoded, this'll probably break. But that's whatever since it would affect like 6 autocomplete components.

Aside from that, anyone using Luduvo LSP via the VSCode extension (which is, thankfully, no one) may have noticed that literally nothing worked as it was supposed to. Thanks to stupidity, I forgot to fully transition anything that said luau-lsp to luduvo-lsp and it broke basically every command. To the 0 VSCode users affected by this for over a week, I apologize for the sloppy job. However, it should work now!

Now onto the release!

[1.70.4L-alpha] - 2026-10-18

Added

• Resources now can have markdown doc strings associated with them, meaning that you can add descriptions to individual resources now
• Builtin Component Resources now provide doc strings when applicable (not all components have doc strings internally)
  • You can use them via the new documentation field in the values section of resource config files:

"luduvo": {
  "resources": {
    "sources": {
      "myCoolSource": {
        "values": [
          "ResourceWithoutDocumentation", // This old version still works
          {
            "name": "ResourceWithDocumentation", // But new resources should really be made using this format
            "documentation": "# This documentation supports markdown (or at least it should)"
          },
          // ...
        ]
      }
    }
  }
}

• More testing files have been added for the python scripts, and the CI workflow now runs them before using them
• A nice little counter program that generates a tree from the luduvo definition files

Changed

• Python component extractors now also extract "custom" components and any documentation strings associated with the extracted component
• Builtin Component Resouces now include components in Luduvo's "Custom" category in the Editor
• Moved around the location of the python test scripts, and the CI workflow now uses them
• Bit the bullet and finally split up and reorganized the hover/definition code. Things were starting to get a bit too messy
• Luduvo Tests no longer rely on Luduvo itself to be installed. I thought this was a good idea, but it was causing more issues than it solved
• Resources in config files now expect an array of dictionaries instead of an array of strings. Its backwards compatible with the old format, so you don't need to change anything if you don't want to

Fixed

• Minor Lint/Prettier checks pass now
• Some broken Hover and completion tests weren't testing what they were supposed to correctly. That is now fixed
• Some Luduvo Tests could just straight up not run when testing specific testing groups due to more stupidity
• Writable server endpoints no longer incorrectly get the read-only tag just because its read only on the client
• Luduvo LSP's extension no longer haphazardly mixes luau-lsp and luduvo-lsp as config names for its settings and commands. If they weren't working before, they should work now. Genuinely, this was one of the stupider things I've done and I don't know how I didn't catch it sooner. Thank god no one has used it yet...
• Resource autocomplete got updated to reflect the many changes made in Luduvo 50

---

External Contributions

• Update Luduvo API types and documentation by @luduvo-lsp[bot] in #6
• Update Luduvo API types and documentation by @luduvo-lsp[bot] in #7
• Update to latest types dump (JohnnyMorganz#1663) by @Jediweirdo in #8

Full Changelog: 1.70.3L-alpha...1.70.4L-alpha

v1.70.3L - 1:1 Parity with... Ourselves

As promised, this is the release where autocomplete actually works again! This has been something I've been planning for a bit, but I never really found the time to fully commit until recently. I intentionally designed it to allow me to iterate on it over time, because I'm eventually hoping to make more than just built-in components/prefabs autocompletable. We shall see what the future holds!

Alongside this release is the VSCode extension. Since the upstream Luau-LSP had already done most of the hard work, it wasn't hard to get them up and running (though most of the "work" for this was done in a different release, not this one). I also wanted to have the release hosted on the cloud so that it autoupdates, but respectfully, screw that. Me and (mostly) @primiti-ve tried to create a marketplace account for the Luduvo devhub and set up automatic release publishing to it, but I think they just hate you and want to make you suffer as much as possible. For Microsoft, we quickly found out that you have to pay to have your stuff hosted on the marketplace under an organization, and Open VSX... well, Open VSX had you doing 100 much just to make an account. Their servers were crashing just trying to sign in, they needed your home address for some godforsaken reason, and the cherry on top is that you have to open a GitHub issue/PR just to have the privilege of hosting a free extension on their store. So for now, you'll just have to put up with precompiled VSIX builds and come back to update it yourself.

Now onto the release!

[1.70.3L-alpha] - 2026-10-10

Added

• A new resources system that inserts autocomplete suggestions without needing to modify the global types file. Doesn't seem like much, but the system its built in such a way that I'll be able to (somewhat easily) extend it to include support for future resource types (events, user-defined prefabs/components, signals, etc.) without needing to rewrite any of it. Probably. Hopefully.
• 6 new settings come with the resource system:
  • luau-lsp.platform.luduvo.resources.groups, which defines all the resource groups Luduvo adds to autocomplete. Each group defines dataType, includeBuiltins (which decides if this extends or overrides the built-in resource suggestions), and a list of sources that contain the contents of each group's resource autocomplete suggestions. For now, you can only use string data types but in the future it'll change
  • luau-lsp.platform.luduvo.resources.sources, which defines all the resource names a specific source takes. There's a provider field that determines how the source is loaded, but for now only provider: "static" is supported (which just loads a list of values)
  • luau-lsp.platform.luduvo.resources.bindings, which allows you to add resource autocorrect to custom function parameters
  • luau-lsp.platform.luduvo.resources.completion.enabled, which globally enables/disables resource-name suggestions to arguments marked with the "resource-constrained" tag
  • luau-lsp.platform.luduvo.resources.completion.disabledKinds, which allows you to disable resource-name autocomplete for the listed resource kinds
  • luau-lsp.platform.luduvo.resources.completion.disabledApis, which allows you to disable resource-name autocomplete for specific API endpoints
• Component autocomplete is back and it comes with Prefab autocomplete as a neat bonus. Core Prefabs/Components only for now, but the Prefabs are dynamically read from Luduvo's roaming so it'll remain accurate when Luduvo updates.
• Hover/Autocomplete/Paramater tooltips report which variables/types that are resource contrained in its markdown menu
• Releases now (hopefully) support VSCode extension builds that put them in different release channels depending on the suffix I give releases. Not actually tested yet
• The api docs scripts now dump prefab info too instead of just components

Changed

• Sync to upstream Luau 0.742

Fixed

• Stopped adding the "L-alpha" suffix to the end of VSCode extension releases so they compile again
• Rich hover mode now applies in active paramater tooltips. Unfortunately it won't be able to be displayed on the top, since I can't control where it shows up...
• Fixed duplicate lines appearing in the hover/tooltip during active paramater tooltip hover

---

External Contributions

• Merge upstream by @Jediweirdo in #5

Full Changelog: 1.70.2-alpha...1.70.3L-alpha

v1.70.2L - Better Hovers Sponsored by Hatsune Miku

Next release will probably be me finishing the component autocomplete revamp, but for now I switched gears to push something a bit different.

In the last release, I also included a poll on what features I should work on next. After waiting for half a day, I only got one vote from a guy named "Miku", and it was to make some better hovers. In their honor, this release was centered on them. Thanks Miku, for being the only one who cared!

Now onto the updates!

[1.70.2L] - 2026-10-01

Added

• Experimental "rich" hover/autocomplete mode that tells you API/type headings, whether the API in use is the client or server version, tags, and everything else I thought you might find useful while you're coding.
• 3 new settings:
  • luduvo.hover.presentation, which controls whether the rich hover mode is enabled or not
  • luduvo.hover.maxTitleLength, which controls the max length of the hover title before it truncates
  • luduvo.hover.maxTypeDefinitionLength, which controls the max length of the hover type block before it truncates
    I may consider generalizing these settings to be enableable outside the luduvo platform since most of this isn't Luduvo-specific, but not right now
• Created a tag system, so that autocomplete can show things about the API without needing a type block in the way. The current tag types are:
  • read only
  • write only
  • deprecated
  • uncheckable, which is for general use of any
  • uncheckable fields, which are for fields that either have any or have a type index with any somewhere in it (it checks nests)
  • uncheckable arguments, which are for function arguments that have an any type
  • unresolvable, which is just when finding a type for said hover errors for whatever reason
  • "resource constrained", which designates that the API endpoint has checks outside of the linted type that aren't known to the LSP (for example, instance:AddComponent(name: string is marked as "resource constrained" because while its reported type is when in actuality, the API endpoint only accepts string names of very specific components). This was the best name I could come up with, so if you have better name suggestions let me know through the forums/bug reports/etc. This was done in anticipation for the component autocomplete rewrite coming either in the next version or the version after that (since its a lot more general in its use now)

Changed

• Luduvo-specific features are now more constrained to the Luduvo platform instead of being referenced in files that are supposed to be for generic LSP things

---

External Contributions

• Update Luduvo API types and documentation by @luduvo-lsp[bot] in #3
• Add luduvo rich hover by @Jediweirdo in #4

Full Changelog: 1.70.1L-alpha...1.70.2L

v1.70.1L - In Sync with Luduvo For Now and Forever

For the first time ever, I got autocreating releases working! Making releases is very easy now and I'm all for it. This has also been a huge update full of changes that you will probably never see because most of them are designed to be basically invisible. Actually, you will see a difference, but it's a regression 😭. Component names won't autofill temporarily until I finish overhauling them in the next update or two.

But in return, Luduvo LSP's definition files will always be in sync with YOUR version of Luduvo from now until the end of time. They're dynamically loaded from Luduvo's own "internal" files, so if they are ever wrong, it's no longer my fault. Regardless, I'm going to keep bundling the declaration files but they're largely redundant outside the definition files. Luduvo just has them sitting in a "defs" folder inside your OS's appdata roaming equivalent. See the README.md for more details on that. For those of you using the Luduvo executable, I also recommend reading the top part of the changelog, as it explains how to use the new settings introduced in this version of Luduvo LSP. You might need them in case something goes wrong during setup.

Now onto the updates!

[1.70.1L-alpha] - 2026-09-28

Added

• Luduvo LSP now dynamically switches between client-specific or server-specific global type files in accordance to the file extension of the file being checked
• Upon load, Luduvo LSP now checks your active Luduvo directory for any global type files and uses those instead of purely relying on the global type files baked into it. Theoretically, Luduvo LSP autocomplete will never be unsynced from the actual state of the Luduvo API ever again
• Luduvo definitions are now loaded using the following priority:
  1. Explicit client or server override file
  2. The active Luduvo installation's per-user data directory
  3. Definitions bundled with Luduvo LSP
• Added 7 Luduvo settings:
  • luduvo.dataDirectory, which tells Luduvo LSP where to find the Luduvo data directory that contains the official global type files
  • luduvo.definitions.serverOverride, which tells Luduvo LSP where to find the server script definition file
  • luduvo.definitions.clientOverride, which tells Luduvo LSP where to find the client script definition file
  • luduvo.definitions.defaultScriptSide, which handles which script side (server or client) to use when the luau file being analysed is not explicitly marked as a server script or a client script
  • luduvo.definitions.globalPolicy, which defines how Luduvo LSP's client/server definition files should interact with the more global luau-lsp.definitionFiles setting
  • luduvo.definitions.conflictWinner, which defines which definition file should win in case of a conflict if globalPolicy is set to combine
  • luau-lsp.platform.luduvo.definitions.exposePrivateTypes, which defines whether private types should be forced to be exposed in the definition files that is fed into Luduvo LSP. Note that this doesn not expose every private type in every file, but specifically the client and server definition files that Luduvo LSP uses during its operation
• A general purpose platform fflag dependancy system that any future platform can use if they need it (no one other than me will need it)
• Definition-loading failures and unmet platform requirements are now reported through upstream's editor messages system where supported

Changed

• Upstream's .client.luau and .server.luau classification code (#1594) has been generalized so that it can be used independently of the selected platform (since I needed a system like it too and like consistency)
• Luduvo is now the default platform. I realized how little sense it makes to have Roblox be the default platform in a repo called "luduvo lsp"
• Global type/definition updater Python scripts have been rewritten for a third time to instead use luduvo's own provided global type files instead of purely trying to derrive them soley from the website. I am legit an idiot for ever doing that in the first place WHEN THE DEF FILES WERE LITERALLY RIGHT THERE SINCE FREAKING LAUNCH. Words cannot describe how dumb I feel from this. The website scrape is still mainly in charge of doc strings and source linking since they will likely have better doc string descriptions for the LSP to use
• Comments from Luduvo's declaration files now provide fallback hover documentation when corresponding website documentation is unavailable
• When using official Luduvo definition files, it is now required that the SolverV2 fflag is enabled since Luduvo's global type files use features specific to it. The SolverV2 requirement is not enforced when types.definitionFiles is set as the only definition source
• The VSCode extension becomes more luduvo-ified as I toy with the idea of releasing it as a standalone extension
• Definition conflicts between official Luduvo definitions and types.definitionFiles now follow the configured global policy and conflict winner.
• Github actions now download the latest release of Luduvo to extract Luduvo's latest global type files for updates

Fixed

• User-provided types.documentationFiles are no longer accidentally overwritten by bundled Luduvo documentation
• Documentation hover's markdown no longer mistakes the --- separator for a header and make the learn more button giant
• test.luau is formatted correctly for what might be the first time ever

---

External Contributions

• Update Luduvo API types and documentation by @luduvo-lsp[bot] in #1
• Sync upstream 1.70.1 by @Jediweirdo in #2

New Contributors

• @luduvo-lsp[bot] made their first contribution in #1
• @Jediweirdo made their first contribution in #2

Full Changelog: v1.69.1L-alpha...1.70.1L-alpha

v1.69.1L - More Builds and Documentation on Hover

More releases! Woo!!! GitHub workflows work, so now everyone, regardless of system, can use Luduvo LSP.

I recommend reading the usage section of README.md if this is your first time using Luduvo LSP. Outside of that, the global type and documentation files have all been moved into a dedicated luduvo-api-docs ZIP since it would be a nightmare making a sepreate release download for every language Luduvo might support in the future.

To save on space, the exes have also been zipped. Let me know if you would rather have them unzipped for better plug-and-play ergonomics

Full Changelog: v1.69.0L-alpha...v1.69.1L-alpha

v1.69.0L - Initial Luduvo support

Below are the binaries and generated declaration files so that you don't have to build it yourself. Marked as prerelease because I did not try like at all

I can only build from Windows and Linux x64 until someone grants access for workers to use a certain GitHub app. You'll have to build it yourself with cmake, or use the globalTypes file and put the path as the value to the luau-lsp.types.definitionFiles setting in the normal luau-lsp. The next build will have all the release downloads Luau-lsp has

If you are one of the lucky few, this will work in all editors that let you repoint the Luau lsp binary through something like luau-lsp.binary and you can point the binary to that. Then if you change your luau-lsp.type.platform to luduvo, it should just work without interrupting whatever else you have saved there