Do these options and the ((options: Record<string, any>) => Plugin) really add anything? Since the plugin is in-memory, it can just capture options from its scope, I don't see what first passing the options into tstl and then back via a factory function actually adds.

I think it's mostly useful for plugin compatibility, this way you can load third-party plugins directly in memory even if they were written for tsconfig the same way and without manually loading it separately first.

It also makes internal representation slightly simpler by separating the responsibility of loading a plugin from importing it, and don't end up with two different kinds of plugin factories.

If removing it, I think the best approach is to remove the callback version (from InMemoryLuaPlugin) entirely, without the options parameter it just needlessly adds another plugin factory type to handle. (see next post regarding lifetime management)

I guess a big plus for the first point is also that it would simplify re-using the same config object between runs (such as in unit tests) and having tstl itself manage its lifetime the same way it would with a tsconfig plugin.

If tstl only accepts a plugin object directly, you'd need to rebuild the config object with a fresh Plugin object each time you use it in case the factory function keeps internal state intended for compiling a single project.

Fair enough, that makes sense

Fair enough, that makes sense