Interesting work.. the MS one may be work in terms of checking build/install against windows... possibly work towards pre-build dist for binary modules. There are quite a few popular modules that are still require gyp/build tools setup. This is problematic in some (windows) scenarios.
Sorry, but I prefer feature based structure... dividing by file type only makes it harder to work on a given feature as you're scrolling across your project looking for the different parts.
Interesting review... another issue with keeping these things in Node, is memory usage... Node really does constrict you on memory usage, to the point you probably don't benefit from a 64-bit version, unless you env is 64-it only which requires it.
Redis is as valuable as extended memory storage as it is a pub/sub.
Angular 2's RTM should have just been Angular 3, that bump would have provided a lot of protection against dated blog articles and documentation out in the wild.
From there, a progressive growth via semver would have been nice with LTS breaks, similar to node and/or React.
Regarding the "uncaughtException", I will usually put enough to log the error as a fatal error to the logger, wait 100ms (for logger to flush) and process.exit(666) ...
Regarding custom net server implementation... JSON.stringify will, by default wind up on one escaped line, you can then use newline (\n) termination for requests and responses, making it quite a bit easier to dynamically extend for future use, as well as being able to stream input/output compared to other multi-line requests and termination.
Did not know about the repl .load, very cool.
Nice work on pulling this together... There seem to be some work towards Ubuntu and Windows (UWP) React Native applications as targets as well.
As an alternative, one could also use React proper with electron and/or cordova for platform specific targets and share more codebase. Depending on your app, this may be a better choice.
Pretty cool, just the same, I find that Observables tend to be a path to spaghetti... I can see this as being useful for example with a standalone form, or where you're enhancing some stand alone, server-rendered content, but this is definitely not the best approach (imho) for a full application.
Can't see tfa/site from work... but not sure I'd put this out there... it's ripe for an injection attack, and there are some relatively small markdown libraries that run fine in the browser, and on the server.
I usually go a couple steps further, which is to fully copy the bootstrap.scss main file as well as variables.scss ... I'll update the bootstrap.scss copy to point to the local variables... I've done mixins in the past but never actually found myself changing existing ones. I'll include my own mixins that references the original.
In this way, I have...
/styles/root.scss
includes bootstrap.scss
/styles/bootstrap.scss
references local vars and mixins, rest from bootstrap
/styles/_variables.scss
copy of bootstrap variables
/styles/_mixins.scss
reference bootstrap's mixins
root is included at the top of the project... Other components will have a .scss next to the component that may include variables and/or mixins as needed.
This way I can have my globals, and what I need inline. Beyond all of this, it's easier to comment out parts of bootstrap I'm not using. As to copying variables.scss, this is because I sometimes find it hard to remember what should/can be replaced. I also will usually adjust the font bases, as well as some of the colors and styling choices in variables directly.
In the end it's a much cleaner codebase.
I usually go a couple steps further, which is to fully copy the bootstrap.scss main file as well as variables.scss ... I'll update the bootstrap.scss copy to point to the local variables... I've done mixins in the past but never actually found myself changing existing ones. I'll include my own mixins that references the original. In this way, I have... /styles/root.scss includes bootstrap.scss /styles/bootstrap.scss references local vars and mixins, rest from bootstrap /styles/_variables.scss copy of bootstrap variables /styles/_mixins.scss reference bootstrap's mixins root is included at the top of the project... Other components will have a .scss next to the component that may include variables and/or mixins as needed. This way I can have my globals, and what I need inline. Beyond all of this, it's easier to comment out parts of bootstrap I'm not using. As to copying variables.scss, this is because I sometimes find it hard to remember what should/can be replaced. I also will usually adjust the font bases, as well as some of the colors and styling choices in variables directly. In the end it's a much cleaner codebase.