discussion points: Tooling group feedback session

[boneskull]

Following up on the first tooling user feedback session, we want to gather points of discussion for future sessions.

From #38, these were the original questions from the first session:

• Describe how your Tooling leverages Node.js.
• Why do you use Node.js for Tooling?
• What's working in the Node.js tooling ecosystem?
• What isn't working in the Node.js tooling ecosystem?
• What's new that could impact Node.js?

We didn't have enough time to cover everything we wanted to--and give everyone a chance to speak--so future sessions should be more limited in scope.

I'll use this issue to gather ideas, and distill them into a "living document" of sorts (a Markdown document, living in this repo) to be used going forward.

cc @dshaw @bnb to confirm I understood this correctly. 😄

ALSO, PLEASE UNDERSTAND: This issue isn't a platform for discussion; we're just making a rough list of topics to discuss.

[boneskull]

One that came up offline (and I think I may have mentioned briefly) in the "what isn't working" category is portability. I'd like to expand on that a bit, from the perspective of a tooling author.

• fs.watch() is seemingly neglected, and doesn't work well outside of Linux, giving rise to userland modules like chokidar. Ideally, fs.watch() would work as intended across all supported Node.js platforms.
• graceful-fs shouldn't exist.
• cross-spawn shouldn't exist.
• More generally, and not necessarily a concern about portability, fs-extra, rimraf and mkdirp shouldn't exist.
• Error codes should be normalized across platforms (@iarna)
• More care given to buffering and standard input/output (@iarna)

[boneskull]

Feature requests

• GPU-accelerated code bindings (original issue; @TheLarkInn)
• Expose allowed command-line flags in machine-readable format (open PR)

[boneskull]

I also want to cc everyone else who participated in that session; please add anything here you want to discuss, but didn't get a chance to. To all of you: This issue is for gathering topics of discussion for future Tooling-specific Node.js user feedback sessions. Your input is greatly appreciated!

• @bamutov
• @benjamn
• @kentcdodds
• @jdalton
• @uttampawar
• @devsnek
• @kellyselden

Please cc anyone else who might want to participate! 😁

[mcollina]

IMHO #59 (comment) is extremely important.

[boneskull]

cc @bahmutov, sorry misspelled it

[boneskull]

Really hoping someone else can add something.

I'm happy to drive the bus here, but there's no point in driving an empty one.

[bnb]

Going to ping a few people who I know that work on OSS projects that use Node.js for tooling in some cases.

To those I'm pinging: we're gathering points to discuss about Node.js + the tooling ecosystem and what we could do better/what's already working well. Would ❤️ your input if you've got the time to share it–and no worries if you don't!

@johnpapa may have some observations from the Angular core community 🤔

Not sure how much RxJS uses Node.js for its tooling, but @ladyleet may have some input (or know someone from RxJS who does!)

Pinging @zeke because I know he does a LOT with Node.js tooling, and works on Electron which has some tooling built in Node.js as well.

@tzmanics may have input from NativeScript/Angular + Node.js backgrounds.

@mxstbr does some pretty impressive work in the React ecosystem and always has super good feedback.

[ladyleet]

Yeah for sure - well you know what is really missing is pinging the folks working on CLIs - they use Node.js a lot of course. This is something I really hope that in the next year or ongoing we can bring to light. It is one of the most essential and important use cases of Node.js IMO.

For RxJS - @benlesh can provide more info.
For Angular CLI - @hansl or @Brocco
For Vue CLI - @yyx990803 or @chrisvfritz
For Ember CLI - @stefanpenner
For Preact CLI - @prateekbh
For Create React App - @gaearon or he can point you.
For React Native - maybe @TheSavior?
For NativeScript - @jenlooper or @sebawita can point you.
For Ionic - @mhartington can point you.

[elicwhite]

I know I have a fair amount of thoughts here but I think @zertosh has a superset of my thoughts so pinging him instead.

I think the main one I’ve talked to @zertosh about is the overhead of starting up a node script. Making scripts fast is hard and one of the main things driving us to experiment more with other languages for scripts.

[ladyleet]

@TheSavior thanks much! @zertosh love to have you as a part of this conversation.

[chrisvfritz]

I'm not sure I have much to add beyond what @boneskull already mentioned regarding portability. That's the only significant pain point that's coming to mind. I personally don't mind pulling in separate packages, but when a built-in exists it's frustrating when it doesn't work cross-platform. A lot of people have to learn that the hard way.

[cb1kenobi]

I am one of the lead engineers for Appcelerator Titanium SDK's Node.js-based CLI's and tooling, which began 6 years. I went through our projects and analyzed the boilerplate functions and dependencies and here's my first pass list of things:

• As stated above, fs.watch() has serious cross platform issues which I have worked around in appcd-fswatcher, namely recursion support on Linux and the ability to watch files/directories that do not exist or require privileges to access.
• It would be nice if path.resolve() would check if the path starts with ~ and replace it with os.homedir().
• os.arch() should report the machine's architecture, not the architecture of the Node binary. A script should be able to identify if it's being run in a 32-bit version of Node on 64-bit machine. We use this for determining which native executable dependencies to install/run and telemetry so we track when we can drop 32-bit support. Side note, I know there was talk of Node dropping 32-bit support, but I don't think the world is there yet.
• Built-in support for check if a path is an executable file. It's not enough to check flags or file extension. For now, we can use isexe.
• Built-in support for which. It is very handy for finding the full path to an executable and ensures that the path is indeed an executable (see previous item).
• Built-in support for generating UUID's. I know there are package name conflicts, so maybe hang it off util or crypto. I know I can generate random bytes using crypto, but I'd like to not have to pull in a dependency to generate a simple v4 UUID.
• A lighter-weight sandbox construct. vm.createContext() is perfect for 100% isolation, but I want a jail. If the code in the sandbox throws a TypeError, I can catch it outside, but I can't do an instanceof TypeError because the built-in types are not the same definition.
• The ability to complete destroy a vm context. You can create contexts all day, but apparently they can only be cleaned up on exit.
• This is a stretch, but temp directory/file creation and cleanup would be awfully nice.
• The ability to spawn another Node process with a TTY context such that the child Node process can pause(), setRawMode(), etc on process.stdin. This would be great for integration testing so we can use mocha instead write shell scripts.

[dshaw]

@boneskull We are looking at 2018-06-08 for the next session.