`require` in bundled scripts

[ThistleSifter]

I've been looking into a better solution for the usage of require in bundled scripts and I've come up with the following plan:

• Add all bundled modules as package loaders.
• Remove the overridden require function and just use the standard one.

This should mean that the loading of any other modules (eg luasocket) will be unaffected by the bundling process.

There are two ways of directly including package loaders.

1. package.preload

package.preload["library.utils"] = package.preload["library.utils"] or function()
-- module contents...
end

2. package.searchers

table.insert(package.loaders, function(package_name)
-- return module wrapped in function from here
end)

By default, require looks for a package loader in the following order (according to package.searchers):

1. package.preload
2. package.path
3. package.cpath

That order can be changed by reordering the table or inserting a function earlier in the package.searchers table for loading bundled modules.

Let me know if you have any thoughts as to which option is better.

(Edited because I initially misread the manual)

Cc @rpatters1

[rpatters1]

I like the idea of not overriding the require statement. I am starting to build in a few more Lua C libraries into RGP Lua and you have to require them to use them.

• luasocket was the OG case. You have to use require to access mime.core.
• I started building inluaosutils in the last release. You have to use require to access it.
• The next release will embed cjson, which will also need require.

To fool the bundler, I have provisionally added a library.require_embedded function. But I would be happy not to need it. Are there any downsides? Will all the scripts have to be modified to use preload instead of require?

[ThistleSifter]

Usage of package.preload would be handled by the bundler. Script authors won't need to change anything.

I can't think of any downsides. From my reading, this is how dynamic loading of modules is meant to be handled.

I'll write up a PR soon.