Managing multi-language project

<p>What is the recommended way to organize a multi-language project?</p> <p>Right now let&#39;s say I&#39;m creating a project that will have javascript, ruby, and go.</p> <p>The desired project structure would look like this. </p> <pre><code>project ├── go │   ├── lib │   │   └── lib.go │   └── main.go ├── js │   ├── lib │   │   └── lib.js │   └── main.js └── ruby │   ├── lib │   │   └── lib.rb │   └── main.rb </code></pre> <p>Right now I&#39;ve thought of a couple ways to get around this multi language debacle.</p> <ul> <li>Develop in the regular <code>$GOPATH</code>, <code>cp -r</code> project for every change.</li> <li>Symlink <code>$GOPATH/project</code> into the multilanguage project</li> <li><p>Develop under a new <code>$GOPATH</code> and change the structure to this for go.</p> <pre><code>project ├── go │   └── src │   └── project │   ├── lib │   │   └── lib.go │   └── main.go ├── js │   └── main.js └── ruby └── main.rb </code></pre></li> </ul> <p>Now all of these ways I&#39;ve thought about getting around the <code>$GOPATH</code> issue have tradeoffs. Does anyone know of a good way around this that will get me close to the desired structure?</p> <p>Thanks</p> <hr/>**评论：**<br/><br/>jerf: <pre><p>You&#39;ll really want to go with the last one.</p> <p>Basically, once you really get going you&#39;re going to discover that Ruby and JS also don&#39;t share the same ideal layout, and that you&#39;ll want to adopt a native layout for them, too. Just go with the most native answer for all of them. Go may be more obviously different but every language&#39;s ideal layout ends up different in the end, especially if you end up using their various package managers or deployment managers that want their own directory layout correctly.</p></pre>threemux: <pre><p>Agree with <a href="/u/jerf" rel="nofollow">/u/jerf</a>, you&#39;ll want to keep everything native if possible. Alternatively, you could use <a href="http://getgb.io/" rel="nofollow">gb</a>, which doesn&#39;t require the use of GOPATH at all and keeps the go code completely self contained. It does force you to use vendoring though, so if that&#39;s a turn off it might not be a good solution. </p></pre>DavidDavidsonsGhost: <pre><p>I personally prefer dividing up by components, because are you going to be looking for the thing in &#34;go&#34; or &#34;SignupServer&#34;.</p></pre>yiyus: <pre><p>Why don&#39;t you go with the desired project structure? For example, if your project is in github.com/user/project, you can import lib as &#34;github.com/user/project/go/lib&#34;. If you expect lib to be used by other developers, I would just have an independent repository for it, else I don&#39;t see what is the problem.</p></pre>