How do you write reusable packages?

[ixtant]

The import function in the Lua SDK has the restriction: "All files imported from main.lua (and imported from files imported from main.lua, and so on) are compiled into a single pdz file, and import runs the code from the file only once. A second import call from anywhere in the pdz will do nothing."

So if you create a helper package which returns an object or a table of functions, you can only import it in one file—the second place you try to import it, it will be nil. This is a problem for how I like to write small packages which return their contents (instead of making them globals).

Potential workarounds:

1. Write my own cachedImport function which stores already-imported packages and returns them. It doesn't work because import requires a string literal; you can't pass a variable as the path. (But I would support this behavior for import as an SDK improvement.)
2. Have my packages expose global functions. I could do this but I don't like it.
3. Import all packages in one central place, store them in a global table, and access that table instead of calling import elsewhere. It's gross, but I'll probably do this.

How do you structure your packages?

[Gamma]

I usually have some global table and import them in main.lua. Then in whatever scripts I need them, I can declare a local const (underscore) to use it without needing to access globals every time.

I’ve never used lua in any other project though, so this might just be the playdate way.

[matt (gingerbeardman)]

Don't miss this trick from Shaun

A list of helpful libraries and code

This is really unintuitive but import already returns the return value of the imported script, but-but imports only work at the beginning of a line, but-but-but, since Lua doesn't really care about whitespace, you can write it like this: local __ = import 'underscore' __.each({1, 2, 3}, print) __({1, 2, 3}):each(print) Both examples now work as expected with an unmodified underscore.lua using this method.

And Nino's custom import trick

Gravity Express

Ditching the import statement to improve boot times As per the docs, the import statement is a function available in the Playdate SDK that is not part of standard Lua. Conversely, the require statement is in every Lua distribution except for Playdate. The import statements are not run by the playdate, but instead by the pdc compiler. import "otherfile" basically means: read otherfile.lua and paste everything you find there at the current position in the current file. This way, you as developer c…

[ixtant]

Thanks Gamma and Matt.

Shaun's trick isn't necessary anymore—in SDK version 2.3.0 this works just fine:

local pkg = import("pkg")

...as long as you only do it once for that package in the whole project.

Nino's trick is really neat. However using playdate.file.run instead of import has the downside (which he notes) of incurring a file read during runtime. I'll probably stick with import for now, but it's good to know about.