go: can we make generated go code more self-contained?
eladb opened this issue · 3 comments
🚀 Feature Request
Affected Languages
-
TypeScriptorJavascript -
Python -
Java - .NET (
C#,F#, ...) -
Go
General Information
- JSII Version: 1.29.0
- Platform: all
- I may be able to implement this feature request
- This feature might incur a breaking change
Description
Currently, the go code generator puts the embedded jsii tarball under a subdirectory called jsii. This means that in order to be able to import this file, other .go files need to know the name of the Go module in which the generated code resides.
For example, the mypackage directory here includes the generated Go code under mypackage.go and this file imports com.example/mymodule/mypackage/jsii (line).
This is okay for jsii-pacmak because it knows the name of the Go module, so it can render this import.
As we are looking into adding support for Go to jsii-srcmak (see PR), it means users of srcmak will need to pass the name of the parent go module into which we are generating source code, and this is quite a burden.
Proposed Solution
We were wondering if it might be possible to avoid the jsii directory altogether and just embed the tarball in the main .go file? Perhaps we can special-case the situation where there is a single .go file? Alternatively, why does this have to be in a subdirectory? Maybe we can just put this in another .go file next to the main file (same as mypackage.init.go) and then it will be possible to simply reference it without needing an import statement.
Yeah this should be doable to embed in the module entrypoint or as a separate file but the same package as the root package in the module.
Yeah... Actually using jsii sub-package might be a cause for collisions of some customer code decides to have a user-defined jsii submodule...
@RomainMuller but this is purely a naming collision right? We can make the sub-package something obscure and worst case scenario a user can alias it or another package if needed to avoid collision.