Node-compatible process module

[sgtcoolguy]

JIRA: https://jira.appcelerator.org/browse/TIMOB-26571

Description:
This is an attempt to expand the global process object to be more compatible with Node when possible.

What's missing?

• A number of the APIs are basically stubs and are therefore no-ops or expected to be unused
• process.getegid()
• process.geteuid()
• process.getgid()
• process.getgroups()
• process.getuid()
• process.hrtime([time])
• process.hrtime.bigint()
• process.initGroups()
• process.kill()
• process.mainModule
• process.memoryUsage()
• process.nextTick()
• process.release
• process.send(message[, sendHandle[, options]][, callback])
• process.setegid(id)
• process.seteuid(id)
• process.setgid(id)
• process.setgroups(groups)
• process.setuid(id)
• The process events aren't really fired outside of warning and uncaughtException. A number of them don't apply, but I think perhaps beforeExit may make sense to hook to our Ti.App event for close.

[build]

	Messages
📖	💾 Here's the generated SDK zipfile.
📖	✅ All tests are passing Nice one! All 3787 tests are passing.

Generated by 🚫 dangerJS against 1744d15

[janvennemann]

Just a minor note regarding formatting of a doc block. Approving nonetheless, since the rest looks good!

[janvennemann]

Remove indentation to match other doc blocks.

[janvennemann]

Again, yes, please! :)

[janvennemann]

@sgtcoolguy i think it should somehow be configurable what node shims we load since there are some node modules out there that change behavior depending on availability of certain built-in node modules.

The popular axios http client for example tries to load the http module when global.process is available. Since we don't have that yet, requiring axios now breaks and our axios-adapter is not usable anymore. A common workaround would be to temporarily deleting process from the global before requiring the module and then re-attaching it.

We either need some documentation that describes these gotchas and how to workaround them or a way to disable the shims if a user does not need them anyway.

[sgtcoolguy]

manually merged

[sgtcoolguy]

@janvennemann Yeah I'm not sure how to handle "partial" node API support. To some degree we may be able to make use of browserify to shim the ones we haven't gotten to, but for example http from browserify will also fail.

We could use some sort of property/build flag to toggle the extensions altogether or maybe using some pattern matching or something?

It's difficult, because even something like trying to get our test suite to use the "out of the box" mocha with these shims keeps exposing more subtle API differences we need to fix. Some of which are much larger architectural issues (like how Android's require() is much more compatible with Node and iOS/Windows are more natively implemented and don't support say module.paths).