This is the latest in a very long and very random line of "screw my project" problems I've been having while trying to build a cross-platform library with NodeJS. The library needs to find the proper Program Files folder based on the OS architecture (Program Files or Program Files (x86)) and apparently nothing I do is capable of properly detecting the architecture, including using your module.

At first I thought this was because AppVeyor was installing 32-bit NodeJS on either architecture, but even with that fixed using Install-Product node $env:nodejs_version $env:Platform to install the proper arch-specific versions it still fails exactly the same as every other time.

I have tried

• Using process/os module's .arch method.
• Using your module.
• Detecting the folders directly -- apparently don't exist/are inaccessible on AppVeyor by default.
• Detecting WoW64 folder directly -- apparently don't exist/are inaccessible on AppVeyor by default.

My detection code is similar to the following:

if (platform === 'win32') {
  if (arch === 'x86') {
    detected = path.join('C:', 'Program Files')
  } else {
    detected = path.join('C:', 'Program Files (x86)')
  }
}

I have been changing the arch === 'x86' part around trying different things -- used 'ia32', 'x64', 'x86', 'ia64', and || combinations of ia32 & x86, but they all either fail completely or always return one value even on a machine of a different arch. Also, even with it testing for explicit values using if/else if instead of if/else it would still always return the value for one arch and ignore the other...lol.

My project is @ https://github.com/l3laze/node-steam-config/tree/new; working in the new branch as it's yet-another-rebuild and I've finally learned to stop doing that directly in a repo/it's dev branch.

I'm guessing this is just going to be something simple that I'm screwing up as usual, but after over 2 days now of trying to fix this I can't keep banging my head against this freaking wall.

Version 12.0.0 of standard was just published.

This version is covered by your current version range and after updating it in your project the build failed.

standard is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/PlatformArch

const {bitness} = await navigator.userAgentData.getHighEntropyValues(['bitness']);

See:

• https://wicg.github.io/ua-client-hints/#user-agent-platform-bitness
• https://developer.mozilla.org/en-US/docs/Web/API/NavigatorUAData/getHighEntropyValues#return_value

Can I create a PR to add esm support?

I have a CLI tool that installs different binaries depending on the system architecture, and it worked fine so far for Windows, macOS and Intel GNU/Linux, but when I tried it on a Raspberry Pi, it installed the x86 binary, which obviously is not the desired effect.

Since Node.js is available on non-Intel architectures too, it would be recommended to support them too, and by all means avoid converting from one architecture to another.

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 11.0.1 of standard was just published.

This version is covered by your current version range and after updating it in your project the build failed.

standard is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Given the migration to Apple silicon, do not assume that if the platform is 'darwin', the architecture is 'x64'.

This seems a lot simpler and should work just as well?

As you know, process.arch and require('os').arch() both return ia32 from a 32-bit Node.js executable.

Assuming running 32-bit Node on 64-bit Linux, the process.arch === 'x64' test is false and proceeds to do WOW64 checks and those will fail on Linux resulting in incorrectly detecting a 64-bit Linux OS as x86 instead of x64.