Add node like api in ch.exe

[Cellule]

Right now it's really painful when trying to run a script both in node and in ch the main reason is with the way the global scope it populated.
See https://nodejs.org/api/globals.html for current list of what node exports.

I don't suggest we implement them all, maybe some simple ones like console, global, __dirname, __filename.
I would love to be able to simply write console.log in a script and it works everywhere.

Plus, with __dirname we could run script loading other script without the need to be in that current working directory.
For instance WScript.LoadScriptFile(__dirname + "\\memset_tester.js"); would work anywhere.

Also, right now if I want to shim print, WScript.Echo and console.log we can't use if(!print) print = console.log because this throws in Node and if(!global.print) global.print = console.log throws in ch.exe

I already implemented some of them locally just to play around, but I wanted people's opinion before I submit it.

[obastemur]

Also, right now if I want to shim print, WScript.Echo and console.log we can't use if(!print) print = console.log because this throws in Node and if(!global.print) global.print = console.log throws in ch.exe

use if (typeof print === 'undefined') instead

[ianwjhalliday]

What sorts of scripts do you run in both? I'm curious since ch.exe is obviously not node, so it doesn't have the APIs and eventing that node does.

Re LoadScriptFile I feel like it was an oversight that it does lookup relative to the current working directory rather than the script file's path. We could consider that a separate bug worth fixing. This has bugged me in the past too.

[Cellule]

What sorts of scripts do you run in both? I'm curious since ch.exe is obviously not node, so it doesn't have the APIs and eventing that node does.

Right now I work a lot with Node+Chakra and sometimes I hit bugs and I need to modify the test file a lot to make it work with ch.exe.

[Cellule]

Re LoadScriptFile I feel like it was an oversight that it does lookup relative to the current working directory rather than the script file's path. We could consider that a separate bug worth fixing

You may be right that we should simply fix this behavior. I highly doubt anyone depends on this method to be relative to current working directory, but I could be wrong which is why I didn't propose this in the first place.

[ianwjhalliday]

Ah, so you run it with ch.exe to debug why ChakraCore is broken, is that it? That sounds legit. Though could you stub out the globals at the top of your script in this situation?

I don't feel strongly one way or the other about adding these, but I do feel a nebulous, instinctive hesitance about adding random globals.

Afaik LoadScriptFile is only used for our tests so I think it is safe to change. @Yongqu might know better though.

[Yongqu]

we have WScript.Echo, and we should be able to override console/console.log use that. you might need to create console object first and/or do something similar to what @obastemur suggested. similar with global/this/window object. __dirname and __filename is something we can add though. We can do it in ch.exe or as our node.chakracore extension thunk?

[ngsankha]

Note that the other JS engines - the d8 shell of V8 or the js shell of SpiderMonkey also don't implement the same. Generally these functions are implemented by the runtimes embedding the engine.

[obastemur]

@Yongqu

__dirname and __filename is something we can add though

Without additional cross platform tooling, this wouldn't be much usable.

@sankha93

Note that the other JS engines - the d8 shell of V8 or the js shell of SpiderMonkey also don't implement the same.

Agreed.

[bterlson]

It should be a non-goal of ch.exe to support node APIs. It is difficult to run scripts across hosts, that much I true, but it seems unlikely right now that everyone (d8, jsshell, jsc, etc) could agree on any one API.

That is why I created https://github.com/bterlson/eshost-cli and related libraries. It can probably help you here.

[Cellule]

Okay, so looking at people's opinion, I think I will close this issue for now. It is true that there are no common API between the main hosts (which I think is sad) and we can shim most of them.
I will however open another issue regarding WScript.LoadScriptFile