Repository navigation
Automate tooling updates #22722
Description
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?
Activity
silverwind commentedon Sep 6, 2018
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 commentedon Sep 6, 2018
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
requirein 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 commentedon Sep 6, 2018
Shouldn't a dynamic require be preserved during bundling if you compile script to script?
ljharb commentedon Sep 6, 2018
@refack i'm not sure what sort of advice you're looking for
refack commentedon Sep 6, 2018
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.@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 commentedon Sep 6, 2018
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 commentedon Sep 6, 2018
@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.mdthere to explain what the group is about.UPDATE: nodejs/tooling's README
refack commentedon Sep 7, 2018
@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-cliwithroolupRE: #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 commentedon Sep 7, 2018
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 commentedon Sep 7, 2018
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 commentedon Jun 19, 2020
There's been no further activity on this in nearly 2 years. Closing. Can reopen if it makes sense to revisit this