Built-In Method of Accessing Common Libraries Like Roact for Plugins

Greetings,

As a Roblox developer, it is currently difficult to incorporate large, but common, libraries into my plugins. Currently, we’d have to:

  • include the module script itself inside of the plugin, or
  • build the library up upon plugin initialization via HTTP requests to Git repositories

Both have their caveats, for example, the first method makes the plugin too bulky in which the actual plugin content may be outnumbered by the library itself. It’s like you need a book for some research project and obviously it’d be impractical to buy an entire library, however you need the contents of that library which may house the book you were looking for.

For the second method, an HTTP plugin request will always need to be allowed, which would be an unnecessary privileges especially if the other parts of the plugin don’t require HTTP.

Therefore, I propose that these libraries be internally included (perhaps within the plugin global?). By libraries, I mostly mean Roact (IDK about Rodux being particularly useful for plugins, but Roact is) and any others accompanying it (e.g. Otter when it officially releases). I envision the use to be like such:

local Roact = plugin.Libraries.Roact --or just plugin.Roact
--or
local Roact = require(plugin.Libraries.Roact)

Basically, it’d give access to the module (either automatically requiring it or we manually have to do it). I’m sure there must be some centralized module system in Roblox’s built-in plugins already (otherwise that’d just be inefficient); after all from what I’ve heard, their UI is mostly managed by Roact. Therefore, it’d be amazing to get hands on up-to-date libraries simply via the plugin global. Comparing this to the book-library analogy from before, it’d be like having access to a public library for that book, which is what normally happens.

Now, this built-in library of libraries would be more useful for plugins than for games. It’s understandable and recommended to manually install modules for a game, which is a project usually many times larger than a single plugin. You wouldn’t have a town without an instituted library, so same applies to games.

If this was added, it’d improve my development experience because I’d be able to create robust plugins via libraries. I’ve heard certain plugin developers backing down from utilizing what they know to be life-saving libraries simply because manually including them in every one of their plugins is too bulky.

Thank you.

11 Likes

How would this handle versioning? I think that’s a big reason why exposing a standard library like this can be a bit tricky. If a new or breaking change is pushed to Roact, you would have to make sure all your code that uses the library gets updated to support the change.

3 Likes

Oh yes, that is quite a tricky issue, which would also persist if you have the library build itself via HTTP request to a repository. Plus, as with these recent game-breaking updates out of the blue and confusion around the deprecation of API, there is an inherent risk with such built-in libraries. After all, the choice still persists of including your version of Roact just for extra security. However, most of the time, Roblox handled libraries often receive backward-compatible updates, so this shouldn’t be a common issue.

I had an idea of the built-in library having different versions of the module within (i.e. plugins.Libraries.Roact['1.3.0']), but IDK how practical it would be to cache all versions internally.

1 Like

Can be fixed by pulling by a release tag / commit, that way you always have the version you expect.

In general what you need is a Lua package manager and a place to store such packages. Roblox should not be providing access to “common libraries” without versioning since the libraries are too volatile compared to engine API which is more of a contract.

4 Likes