Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

go: can we make generated go code more self-contained? #2847

Open
1 of 7 tasks
eladb opened this issue May 20, 2021 · 3 comments
Open
1 of 7 tasks

go: can we make generated go code more self-contained? #2847

eladb opened this issue May 20, 2021 · 3 comments
Labels
effort/medium Medium work item 鈥撀燼 couple days of effort feature-request A feature should be added or improved. language/go Regarding GoLang bindings p2

Comments

@eladb
Copy link
Contributor

eladb commented May 20, 2021

馃殌 Feature Request

Affected Languages

  • TypeScript or Javascript
  • 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.

@eladb eladb added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels May 20, 2021
@MrArnoldPalmer
Copy link
Contributor

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.

@MrArnoldPalmer MrArnoldPalmer added effort/medium Medium work item 鈥撀燼 couple days of effort language/go Regarding GoLang bindings p2 and removed needs-triage This issue or PR still needs to be triaged. labels May 20, 2021
@MrArnoldPalmer MrArnoldPalmer added this to Backlog in Go General Availability via automation May 20, 2021
@MrArnoldPalmer MrArnoldPalmer removed this from Backlog in Go General Availability Dec 21, 2021
@MrArnoldPalmer MrArnoldPalmer removed their assignment Dec 21, 2021
@RomainMuller
Copy link
Contributor

Yeah... Actually using jsii sub-package might be a cause for collisions of some customer code decides to have a user-defined jsii submodule...

@MrArnoldPalmer
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/medium Medium work item 鈥撀燼 couple days of effort feature-request A feature should be added or improved. language/go Regarding GoLang bindings p2
Projects
Status: Todo
Development

No branches or pull requests

3 participants