main difference from all of this tools, that they try to create bridge between different shell types, instead of providing same API, integrated with other tools.

also, xeon.js, xeon github - 1 result

It doesn't matter that you can find it, but that the name is obviously in wide use as a trademark in the technology space.

Intel.js or the.js would be just as easy to find, yet that's not the issue here.

Exactly, he knows what he's looking for, exactly - also because of the HN post and release google's search ranking will be rating it higher than in the future. Say you search for https://www.google.com.au/search?q=xeon+code or something similar - you're not going to find it. OK maybe you should be better with your search terms but still, can we stop naming tech things the same exact name as other common tech search terms?

If I understand you right, child process is made by utility that check your local version and laters to notify your for updates. It should only be called once an hour

It not depend on Node.js.

Xeon just add ability to use npm as your package manager, why use tools like bpkg or something else if you can use great environment that trusted by thousands people.

Xeon bundle should be made on dev step, you should not bundle it on real server .etc where u use this script.

Because thousands of people place their trust poorly.

Do you have any specific complaints with npm?

Reliance on transport security instead of providing cryptographic verification of code is my biggest beef, very closely followed by what is essentially a nonexistent reputation system (or, in lieu of a code reputation system, a curated selection of packages).

glag to see that you got my point, maybe for now its kind like early version, but it will make sense.

better management of your dependencies, also bundling to single file for easier distribution. In future transforming scripts with plugins means reusing fish shell functions in bash scripts .etc Also each shell has different syntax for sourcing files.

If you're needing to manage dependencies for a bash script, are you sure you're using the right language for the job? I'm not convinced that mixing and matching functions from different shells is a good thing.

I like to modularise my shell scripts for maintainability reasons. It would be nice to be able to just "pull in the pieces" as needed from my collection of components instead of, as I currently tend to do, re-including them wherever I'm using them.

I guess I'm having trouble seeing the use-case for having large enough shell scripts to require splitting them up into modules.

What types of functions do you write in shell that you need to re-import?

How is this not achievable by the source builtin?

It's perfectly feasible to have small bash scripts, library functions of sorts, and source them in the script you want to use them in.

At that point why not just use a battle-tested config management tool? Ansible, salt, chef, puppet...