Skip to content

Conversation

@MCJack123
Copy link

This PR adds two new configuration options, which control how the lualib bundle is saved to disk:

  • luaLibName: Sets the name to use for the lualib bundle. For example, I find the name lualib_bundle to be vague, so I usually change it to typescript to make it clear what the library is for.
  • luaLibEmit: Setting this to false prevents the lualib bundle from being emitted. This is useful to avoid storing lualib in bundled code when it's available outside the bundle already, or simply to reduce generated file bloat.

These options have been useful for my environment, where I have a multitude of common libraries in a store made available system-wide. Being able to change the name allows me to use a more descriptive file name in that store, and being able to suppress its generation means I don't have the duplicated file dangling around in bundles or the build directory.

Neither of these options can be accomplished through plugins. Changing the name in the generated code could be done with moduleResolution (I haven't tried), but it would not change the generated file's name on disk or in a bundle, and would potentially break other parts of the code. Suppressing emission can't be done for a bundle, since the file is incorporated between afterPrint and beforeEmit with no chance to intervene.

These changes will not affect users who do not use them; all default settings match how they were before.

@MCJack123 MCJack123 marked this pull request as ready for review October 12, 2025 05:36
@lolleko
Copy link
Member

lolleko commented Oct 23, 2025

I think adding luaLibName would be fine, but It would be better if we can agree on a more descriptive name instead of making it configurable e.g. typescript_lualib instead of lualib_bundle...

Regarding luaLibEmit I would have thought that setting lualibImport to None would prevent the file from being emitted.

@MCJack123
Copy link
Author

Regarding luaLibEmit I would have thought that setting lualibImport to None would prevent the file from being emitted.

That would prevent the lualib from being imported entirely, i.e. there would be no require for it at all, which I want to keep in my applications. All I want is to maintain the require calls without writing the lualib to a bundled output.

@Perryvw
Copy link
Member

Perryvw commented Nov 2, 2025

This seems like a very specific use-case I would rather fix with the use of our existing plugin infrastructure rather than pulling this logic and configuration complexity into tstl core. I'm currently lacking sufficient motivation to want to merge something like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants