v3.41.0

I recently introduced some changes to how the require file was loaded and subsequently how modules would be loaded in the future, i.e. "modules v2". Alongside a new package searcher, this would allow for loading internal modules directly - rather than lazy-loaded via calls to lib.

Currently, this only supports two modules: Class, and DataView (the former being functionally identical to lib.class).

local Class = 'Ox.Class'
local DataView = 'Ox.DataView'

Some more information is available here.

---

With that out of the way, I'm announcing another major change to how require works. This is being done to ensure the module system can be standardised and used in other projects without adding ox_lib or any full resource as a dependency.

So, I've created cfxlua-require.

It's not a full resource and only needs to exist in your resource directory for other resources to find and load it. ox_lib will continue to work exactly as it did before and you don't need to do anything - otherwise you can include it inside your own projects and load it like any other script file, or add shared_file '@require/init.lua' to your fxmanifest.

If you are cloning this repository then you will also need to clone this new one; otherwise all releases will now bundle cfxlua-require alongside ox_lib.

The biggest reason for this change is because some project maintainers will go above and beyond to avoid adding third-party resources as dependencies, and whilst it's fine to use and redistribute according to the license it isn't exactly user-friendly for systems to have subtle behavioural differences, incompatibilities, and conflicting globals. ESX, for example, has both esx_lib and es_extended setting up require in ways that may cause problems in the future.

Features

• use cfxlua-require to provide module system (Linden)

Bug Fixes

• package/acl: incorrect export call in removeAce (Linden)

Chores

• add dependency to readme (Linden)