Proposal to streamline installs

[springmeyer]

/cc @yhahn @rclark @ianshward.

Now that this repo (node-cpp11) is off the ground I'm seeing obvious potential to streamline our method of mirroring and installing node. Below l've summarized the situation and possible improvements for your feedback.

The current situation is:

• Mapbox Studio on windows depends on custom-built Visual Studio v140 C++11 (aka VS 2015 or 2014 CTP 4) windows binaries from our node fork: https://github.com/mapbox/node. This is absolutely necessary to ensure Studio works on Windows because we require C++11 support that only works in VS >= 2014 (not 2013) and the nodejs binaries don't support it.
• We install these custom c++11 enabled windows binaries from https://mapbox.s3.amazonaws.com/node-cpp11 when packaging studio (code)
• Mapbox Studio for mac and linux still pull binaries from the default mirror of https://s3.amazonaws.com/mapbox/vendor/nodejs (code)
• The install-node script is the only tool that can easily install from either of these s3 repos but being bash only works on unix. This is fine however because we package Studio for Windows on linux.
• The Appveyor Studio scripts use a few lines of powershell to install the vcredist and node.
• Most of us developing on Studio and other node apps are likely using other methods to install node like nvm or homebrew.

Problems and room for improvement:

• We should only maintain one s3 repo as an alternative to nodejs
• Blue sky: we use the same method to install node everywhere resulting in the same binaries everywhere both in packages like studio and in normal everyday dev.

Ideas for streamlining:

1. Start pointing install-node at s3://mapbox/node-cpp11 instead of s3://mapbox/vendor/nodejs by default which would drop the need for the install-node ./util/recache script. The implication of this is that linux deploys would start using Node compiled with clang++ on ubuntu precise instead of Node compiled with and ancient g++ on an ancient centos machine (what nodejs org uses). There should be absolutely no problem with this: the only difference would be that our node might run a bit faster and will not work on ubuntu older than precise.

2. Instead of s3://mapbox/node-cpp11 create a new bucket called node-cpp11 and enable as an s3 "website" with the ability to serve an index doc. This would allow users of NVM to use our mirror by setting export NVM_NODEJS_ORG_MIRROR=http://node-cpp11.s3-website-us-east-1.amazonaws.com in their .profile. The benefit of this would be that NVM users on OS X would then get C++11 enabled builds of Node. This is not required but would be ideal: currently both libstdc++ is used by the nodejs binaries and libc++ is used by our C++ addons. This works because of great efforts of Apple to have ABI compatibility between the two implementations of C++ but is not ideal. The lack of ABI compatibility between each Visual Studio version on windows is the reason for having to build our own node binaries for Windows in the first place, so now that we're off on this journey I think it makes sense to encourage the same approach for OS X.

[yhahn]

We should only maintain one s3 repo as an alternative to nodejs

I think we should continue to maintain two. The install-node s3 mirror is for deployment reliability (ie. uptime). The node-cpp11 s3 mirror is for our windows cpp11 supported builds of node. Combining these would make the reasons for these mirrors existing ambiguous and confusing.

Blue sky: we use the same method to install node everywhere resulting in the same binaries everywhere both in packages like studio and in normal everyday dev.

I think the only honest way to do this is for node to support cpp11 on windows and it's better for us to let that happen on its natural timeline.

---

Overall: I'm ok with the exceptions and weirdnesses of node-cpp11 install for Windows because it's honest about what we're doing. Windows + cpp11 right now is an exception, we've forked specifically for that exception, and we should not use our fork anywhere else because the reason we forked was for Windows.

Our code should express that exception, not hide it.

[springmeyer]

I think the only honest way to do this is for node to support cpp11 on windows and it's better for us to let that happen on its natural timeline.

Some sense on why the natural timeline is still not clearly on the horizon for node.js 0.x: nodejs/node#374 (comment).

[springmeyer]

The upcoming node-mapnik release: v3.6.1 will work fine with the stock nodejs binaries. So this repo has been deprecated: https://github.com/mapbox/node-cpp11/blob/master/README.md#deprecated