Question: Is there a way to emit current matrix information in user code?

[am11]

With multiple node-like runtimes (sass/node-sass#655), there is are use-cases which demand awareness of current runtime (io.js, node.js, atom-shell).

On TravisCI, we can call Linux which node command to get the full path of the executable the current matrix is using (they switch the version with nvm and hence which returns the absolute path to active version's executable). Is there a way to get that information from AppVeyor?

Note that this is different that identifying the runtime within JS script. We need it to instantiate the npm jobs defined in package.json (such as npm test) with corresponding runtime (as opposed to generic node node_modules/blah).

[am11]

@FeodorFitsner,

Here is the commit that is failing because npm test is invoked by node.js with "io.js job": https://ci.appveyor.com/project/sass/node-sass/build/509/job/j64xahfv6bej00br#L191

The corresponding TravisCI job is https://travis-ci.org/sass/node-sass/jobs/50524897#L582. You will notice that io.js job, all calls to node are redirected to io.js.

I think this could be the better solution than making users write a runtime-redirection script for npm?

[FeodorFitsner]

Oh, could you please elaborate what do you mean?

[am11]

With io.js job, node should be an alias to iojs.exe.

[FeodorFitsner]

Right, there are two similar executables in io.js distribution:

[am11]

Thanks for pointing that out. I did not noticed that up until now that io.js packs binaries with both aliases.

The trouble is, our script relies on process.execPath property to detect the current runtime. The reason why we don't have this issue with TravisCI is that process.execPath in io.js path actually returns /path/to/io.js/iojs executable with command run through node. On AppVeyor, it returns \\path\\to\\io.js\\node.exe, where the problem occur. Would be nice if you guys can figure out the way TravisCI is handling it (using nvm).

[am11]

@FeodorFitsner, nvmw downloads only io.js and then they make a copy of alias-node.cmd to node.cmd in iojs version installation directory like this: nvmw.bat#L170, where alias-node.cmd has the canned content:

:: Created by nvmw, please don't edit manually. 
@IF EXIST "%~dp0\iojs.exe" ( 
   "%~dp0\iojs.exe" %* 
) ELSE ( 
   iojs %* 
) 

node-sass uses C++ add-on and it will cause many issues only by using different exec (which emits different process information), not only by node-sass but also the pangyp, which is a cross-runtime build tool for all iojs, node.js and atom-shell.

Which means we do not need node.exe in iojs folder. All we need is node.cmd like the one nvmw has to offer. Again the only difference between iojs.exe and node.exe with same version is the different process information, on which some script are relying heavily. And IMO this is the only use-case in io.js job: to use iojs.exe when the command is invoked with node or iojs.

[FeodorFitsner]

I'm not sure the way you detect node.js/io.js runtime is correct. You rely on availability of redirecting node.cmd on Windows platform, however standard io.js distribution doesn't include it. This batch is nvmw-specific feature. If I use node-sass on my Windows with node.exe from io.js distribution the tool will detect it as node which is incorrect. Or I just don't understand the whole logic behind that?

[am11]

Here is the latest version: extensions.js#L11-L24. This is still debateable how to identify the runtime as you can see here: nodejs/node-gyp#564. Meanwhile our solution to identify runtime is working out fine.

For Linux, io.js provides a symlink called node which points to iojs (4bytes) in bin/ dir, which nvmw mimics via node.cmd. On Windows we can also create a symlink, which this line ^† resolves to real executable. The decision io.js made specifically for Windows is unreliable IMVHO. Since Windows symbolic links are not sharable FS objects, and they actually reflect the real path as soon as you try to move, copy or package it to a zip, node.cmd is the only solution we can propose on io.js issue tracker. Meanwhile AppVeyor can adapt nvmw approach.

^† that line is not necessary to resolve the symlink on Linux, it is also a Windows-only issue in libuv. see: nodejs/node#851 & libuv/libuv#206.