Appveyor build pulls in ia32 version of Node despite x64 env

I'm working on a PR to package up golint in linter-golinter. It's runs fine in Travis and CircleCI but fails in Appveyor. The error has to do with cross-compilation.

For whatever reason, although the appveyor platform is specified as x64 it is pulling in an ia32 version of Node. If this could be representative of an actual user installation then I will need to adjust some things to handle cross-compilation, however it just looks a bit off to me.

Here's Appveryor's log:

Using Atom version: 
Atom    : 1.16.0
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0
Using APM version: 
apm  1.16.1
npm  3.10.5
node 6.9.5 ia32
python 2.7.13
git 2.12.2.windows.2
visual studio 2015
Downloading package dependencies...
Installing modules done
Using Node.js version:
v4.8.2
Using NPM version:
2.15.11

Versuses Travis:

Using Atom version:
Atom    : 1.25.0
Electron: 1.7.11
Chrome  : 58.0.3029.110
Node    : 7.9.0
Using APM version:
apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.25.0
python 2.7.11
git 2.14.2

So I guess my question is A) would this be representative of an end user install and B) if not what could I do to assist in ensuring it's pulling in a version that matches the environment?

A) would this be representative of an end user install

Unfortunately, yes it would: There are many Windows users that initially installed Atom back when there were only 32-bit builds available, and have simply been updating since then, as the 64-bit build requires a manual install for these users.

B) if not what could I do to assist in ensuring it's pulling in a version that matches the environment?

It looks like this is actually a bug in this line:

ci/build-package.ps1

Line 32 in 71af3c6

$source = "https://atom.io/download/windows_zip?channel=$script:ATOM_CHANNEL"

It's currently hard coded for the 32-bit build (/download/windows_zip) instead of a dynamic choice of the 64-bit build (/download/windows_x64) where usable.

Thanks for the quick reply. Yeah, I guess it would be representative. As such, glad this bug existed. That being said, there probably aren't allot of cases like this one where such a thing would be desirable / helpful.

I've fixed the issue on my side in the ngo module, just working on tests for it. I'm going to close this issue as this was an edge case, but I'll try to put together a PR for that once I close this other stuff out.