I'm currently planning an experimental fork of GopherJS that adds a compilation output mechanism I first brought up in #524. This issue is to track notes / ideas / results of this experiment, to evaluate if the mechanism might be useful to include in GopherJS, and if it's worth using over allowing GopherJS to produce its own output.

Goal: Build a compiler mode that produces a 1-1 pairing of Go package -> JS package with TypeScript definitions.

Motivations / Logic:

• TypeScript provides strong typing to the JavaScript language, and is seeing rapid adoption in the ecosystem due to its additive nature.
• WebPack is facing similar widespread adoption, due to its ability to efficiently process asset pipelines, cache results, and build hot-loaded bundles for development and production.
• WebPack is also including building "tree-shaking" capabilities, where dead code is eliminated automatically at build time.
• Large web-apps are usually written in TypeScript. Developers may want to import some of their Go code for use in the browser, without migrating completely to Go.
• Go follows a strong package based architecture, which is similar enough to the ES6 package architecture to work in a 1-1 mapping (e.x. - init() calls can be executed at the module load time).

User-Story:

A developer has built an existing web-app for their project. They have Go code they use in their CLI that handles some concurrent-heavy behaviors that are optimal for Go code-sharing into the web browser. They want to call Go code from TypeScript in a type-safe way, without having to re-write the Go code in JS or track changes to the Go code that might require updates to the hand-written definitions.

Secondary/tertiary ideas:

• WebPack plugin to handle importing Go code by paths directly (out of the goworkspace), along with go get etc as build steps.

Implementation Approach:

• Define a mapping between Go package paths and NPM package names (likely developer specified, with some sort of registry / package.json in the root of the code project).
• Map Go imports of other packages to require statements, possibly in ES6, that WebPack can statically analyze and optimize.
• Produce JS packages for each Go package, possibly tracking version compatibility (through a static analysis results file, perhaps?)