require polyfill

[danports]

Older versions of ComputerCraft like the one I'm running (1.74) do not support require. That means a lot of code in prism-core and libraries that depend on it rely heavily on os.loadAPI and the global environment, which is not ideal, and results in a lot of hacks to work around the fact that os.loadAPI will happily load the same API multiple times.

[tomodachi94]

Odd Stråbø (@oddstr13) made a port of require for older versions of CC. If you create a script that allows people to put startup files into startup.d, and then put cc-require into there, it will work as expected. (This is the approach I recommend for bootstrapping my libraries on older versions.)

You'll need to modify package.path to add your folder that contains the file, but it should work.

[tomodachi94]

(I'd be willing to help you port your library to use require, just send the word and I'll start working on a PR.)

[danports]

Thanks! Sure, I'd be happy to look at a PR for this. My interest in writing CC code comes and goes, but recently I had been thinking about starting a new server with one of the more recent CC forks, so a require refactoring (with or without a polyfill, really) would certainly be handy. Ideally, we'd pull this off in a phased way, so that packages still using os.loadAPI don't break if prism-core has been switched to require - I have a lot of code that depends on prism-core, some public like amber and prism-rails, but a lot more (for storage, crafting, inventory management, building, etc.) that I haven't gotten around to pushing to GitHub yet.

[tomodachi94]

I'm currently working on a script that will modify os.loadAPI to try dofile first, so loadAPI could be phased out internally but other scripts using it would still function properly. (I haven't tested if it persists it's changes, but I think it does.) Do you think this would work?

[danports]

Overriding os.loadAPI should work - I've used that technique before in amber and it's worked fine for me.