I recently created an exportable Go package from StaticBackend, an open source backend API which was self-hosted.I ended up using the internal package way to heavily and this design decision bite me when I decided to create an exportable package. Now all things that needed to be expose that was in the internal package had to be refactored into their own packages.Links:<ul><li><a href="https://github.com/staticbackendhq/core">StaticBackend repo</a></li><li><a href="https://pkg.go.dev/github.com/staticbackendhq/core/backend">Go package</a></li></ul>

I recently created an exportable Go package from StaticBackend, an open source backend API which was self-hosted. I ended up using the internal package way to heavily and this design decision bite me when I decided to create an exportable package. Now all things that needed to be expose that was in the internal package had to be refactored into their own packages. Links:StaticBackend repoGo package

I recently created an exportable Go package from StaticBackend, an open source backend API which was self-hosted.I ended up using the internal package way to heavily and this design decision bite me when I decided to create an exportable package. Now all things that needed to be expose that was in the internal package had to be refactored into their own packages.Links:<ul><li><a href="https://github.com/staticbackendhq/core" rel="noopener noreferrer">StaticBackend repo</a></li><li><a href="https://pkg.go.dev/github.com/staticbackendhq/core/backend" rel="noopener noreferrer">Go package</a></li></ul>

Share 010: internal package gotchas

Sign up to save your podcasts

010: internal package gotchas

010: internal package gotchas

More shows like go podcast()

Cup o' Go