-
-
Notifications
You must be signed in to change notification settings - Fork 181
New option recompileLuaLib: Recompile the Lua standard library with custom plugins. #1656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Perryvw
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand how this relates to #1478, nothing has changed there, has it?
wrt #1502, the idea is the user can supply their own lualib implementation, I'm not sure simply recompiling the existing lualib with plugins is what we're after. If I wanted to completely replace a lualib file how would I do it?
I'm not sure what the reason would be for wanting this recompilation mechanism?
| transpiledFiles = []; | ||
| } | ||
|
|
||
| const proxyEmitHost = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what this does or why it's needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we write lualib_module_info.json when we recompile lualib_bundle.lua, this proxy make sure we don't overwrite the exists one, but collect by our recompile instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't you solve this in lualib.ts where you start the new transpile (with this explanation as comment because code is very hard to understand), instead of here in the global transpile process?
| feature: LuaLibFeature, | ||
| luaTarget: LuaTarget, | ||
| emitHost: EmitHost, | ||
| useCache = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get what the point of this getCache in these functions is, why would we no longer want the cache? In my mind either we read from disk or we recompile, but either way we want to cache the result there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because every time we recompile, we need new fresh LuaLib code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't understand this: Either we read the file from disk and we want to cache the data we read, or we recompile and we want to cache the compilation result. Why would we ever want to skip the cache in either case? I don't see why the lualib would change after first compilation within a single tstl run
|
#1502, I explain that, user may want to recompile # into Len() in all files including LuaLib. all of these 3 issuss can be perfectly resolve by this recompileLuaLib option. |
|
I write so many plugins and copy tons of code in |
|
Here we have 2 user cases:
with proposal in #973: lualib?: Partial<Record<LuaLibFeature, string>>
with this option: recompileLuaLib
const plugin: tstl.Plugin = {
beforeEmit(program: ts.Program, options: tstl.CompilerOptions, emitHost: tstl.EmitHost, result: tstl.EmitFile[]) {
for (const file of result) {
if (file.outputPath == "xxx/lualib/Class") {
file.code = "local MyCustomClass = {};";
// or compile typescript
file.code = tstl.transpileString("const MyCustomClass = {};", options).file!.lua!;
}
}
},
};
Sorry I don't make those pro and con very clear last night, hope I done it now. |
| feature: LuaLibFeature, | ||
| luaTarget: LuaTarget, | ||
| emitHost: EmitHost, | ||
| useCache = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't understand this: Either we read the file from disk and we want to cache the data we read, or we recompile and we want to cache the compilation result. Why would we ever want to skip the cache in either case? I don't see why the lualib would change after first compilation within a single tstl run
test/transpile/lualib.spec.ts
Outdated
| .expectToHaveNoDiagnostics() | ||
| .getLuaResult(); | ||
| const lualubBundle = transpiledFiles.find(f => path.basename(f.outPath) === "lualib_bundle.lua"); | ||
| expect(lualubBundle?.lua).toContain( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also add a test with bundling?
| transpiledFiles = []; | ||
| } | ||
|
|
||
| const proxyEmitHost = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't you solve this in lualib.ts where you start the new transpile (with this explanation as comment because code is very hard to understand), instead of here in the global transpile process?
add test LuaLib recompile with bundling option.
Implementation about #1478 #1502
all
luaLibImportoptions are supported.