Automate tooling updates

[BridgeAR]

It would actually be nice if we could add a bot that fetches module updates in a cron job and opens PRs for those.

That would be helpful for:

• acorn
• eslint
• remark things

And likely more. We also do not have to worry about being forced to update as we can still decide to close the PR if there's e.g., an issue with that release for core.

@nodejs/automation @nodejs/build-infra what do you think?

[silverwind]

Agree. I'd also like to see us bundling those tools. We could for example compile them down to single files using tools like Webpack. It would certainly help with the git performance to not have thousands of file changes every update.

[refack]

Ohh @silverwind thanks for the reminder, that I should revive #20109.
On that note, it's not simple to "roll-up" the tools into a more compact form, specifically because they are based on plugins, and so use dynamic require in varied ways.

/PING @jdalton @ljharb any advice RE https://github.com/nodejs/node/blob/master/tools/node_modules/eslint/lib/util/module-resolver.js

/CC @nodejs/tooling (first!)

[silverwind]

dynamic require

Shouldn't a dynamic require be preserved during bundling if you compile script to script?

[ljharb]

@refack i'm not sure what sort of advice you're looking for

[refack]

Shouldn't a dynamic require be preserved during bundling if you compile script to script?

From what I've experienced, since most of those roll-up tools are based on replacing require. As long as they can deduce what will be "requires" they can build a map. When it's a dynamic require the borke.

@refack i'm not sure what sort of advice you're looking for

@ljharb, eslint is heavily plugin based, and does a lot of dynamic requires. Any best practices about how to handle such scenarios (if I wanted to browserify/webpack/roll-up it).

[ljharb]

um, why would you want to use a bundler on dev tools? bundlers are primarily for serving content to browsers; rollup's use is to reduce the entry points in a published package. Neither really applies to node core.

[boneskull]

@refack re @nodejs/tooling -- this issue regards node's tooling itself, which is out of scope. The "tooling" initiative is roughly explained as "improving the experience of Node.js when using node as tooling"--essentially, the "CLI" use case vs. the "deployed service" or "web app" use case, which already has strong representation.

I'll go ahead and update the README.md there to explain what the group is about.

UPDATE: nodejs/tooling's README

[refack]

@ljharb I know I'm trying to round a square in this case by using the currently available bundlers, but I've had success bundling remark-cli with roolup RE: #20109.

@boneskull IMHO bundle-ability is a goal for general tooling enablement (we can argue on priority later). I believe that single file cohesive packing has many benefits for tools. But at the moment CJS based tools are hard to bundle, and node doesn't provide enough hook point to achieve this.

[ljharb]

Bundling code you wrote and published is one thing; bundling code for a cli that you didn’t write (like eslint) makes no sense to me. What are you hoping to gain?

[refack]

I wrote some perceived benefits in nodejs/tooling#3
Mainly I want less files in the repo, it's a pet peeve. But the rest of the usual suspects for compilation: size, speed, unbreakable FS structure, opaque to my IDE, no dependency version clashing, zero effort install.

[jasnell]

There's been no further activity on this in nearly 2 years. Closing. Can reopen if it makes sense to revisit this