Refactor stringify, add tests for it, and use it in some exports#2347
Conversation
|
3cde972 converted mods.lua to use this. This was mostly done to test performance (it's now only a bit slower, probably because the string is saved in memory instead of being written directly). If it's not ok, feel free to revert the commit. It does change the style of the written file as originally each mod was on it's own line. I think this might be an improvement since the statOrder seems to often change and it makes finding new/removed mods from github diffs pretty hard. I've not replaced |
This reverts commit c0b3cf1.
Use Lua's quoted-string formatting to safely escape quotes, backslashes, control characters, and newlines. Remove the now-redundant manual escaping from the flavour text exporter and add tests for strings and keys. Fixes the export of tags for some mods as I didn't realise that was an issue
LocalIdentity
left a comment
There was a problem hiding this comment.
I fixed a minor issue with some lua string stuff and also removed the mod export changes
It did highlight that we were missing the export of mod tags for some mods though so I fixed that
Description of the problem being solved:
Doesn't solve anything, but I think this makes it easier to export files, which this program does a lot of of. I think the style of manually writing output files character by character is pretty difficult to work with, and something like this means you can just build a table and do
utils.saveTableToFile(path, table, description). SeeflavourText.luafor an example. This makes it MUCH faster to add more data imports later. For example adding a field which contains a table later is very easyThis also rewrites
stringify()and makes it work with a lot more tables. For example multi-line string keys, table keys, mixed tables work now. Some of the table types that Lua supports like function keys were skipped. There is added whitespace, which formats files in about the same way as JS'sstringify(obj, null, "\t")would:While this looks crazy on the loc meter, I think this is also better because diffs will highlight fewer differences, and this will probably help with conflicts when e.g. rebasing a branch.
Steps taken to verify a working solution:
Link to a build that showcases this PR:
Before screenshot:
After screenshot: