Created an NpxToolBase as an inheritable Subsystem for nodejs tools
#17567
Conversation
… for debate) with version option
| from pants.option.subsystem import Subsystem | ||
|
|
||
|
|
||
| class NpxToolBase(Subsystem): |
There was a problem hiding this comment.
Happy to bikeshed on this name. NpxToolBase, NodeToolBase, NpmToolBase - I'm not sure which is the most precise, but extensible... Also may not matter, since it can always be changed later if need be.
There was a problem hiding this comment.
I'd say NodeToolBase? We call the Python equivalent PythonToolBase, not PipToolBase or PyPIToolBase.
There was a problem hiding this comment.
This is somewhat complicated -- I suggest NpxToolBase, as npx is a tool launcher, and node is not (it's an arbitrary script launcher).
There was a problem hiding this comment.
it's an arbitrary script launcher
Feels like that would line up more with PythonToolBase in that case.
The only reason I was thinking NodeToolBase is that fundamentally, all of the tools need to be NodeJS tools. However, the same logic applies to npm and npx since it's the same ecosystem and suite of tools.
In Slack, @kaos mentioned
I’m not sure if there’ll ever be a risk for another node tool to not fit under that subsystem.
That's a point I just never thought about - and I don't know if it's the case or not.
There was a problem hiding this comment.
Things launched by yarn come to mind as a good reason for being specific about the launcher.
There was a problem hiding this comment.
Node is a runtime, so these are "tools that run on node" in the same way that PythonToolBases "run on the python interpreter" and JvmToolBases run on the JVM. So I think NodeToolBase is the right parallel?
Very roughly, Npx is to Node as Pip is to Python as Coursier is to JVM?
There was a problem hiding this comment.
Leaving NpxToolBase for now. Down the road when we think about potentially incorporating yarn, pnpm, or whatever the flavour of the month is in the future - we can revisit.
@benjyw npx isn't a package manager per se, but (more or less) an alias for "npm install" and then "npm exec" (https://docs.npmjs.com/cli/v7/commands/npx#npx-vs-npm-exec). So, npm is the pip.
This line of thinking has gotten me to the conclusion that NpxToolBase is better for now, specifically because it brings with it one piece of implicit info. The package MUST be executable with a bin folder/file specified in the package.json.
For example: npx dayjs errors out with npm ERR! could not determine executable to run.
So, NpmToolBase is incorrect, because the intention is an executable package. And for the same reason, I think NodeToolBase is incorrect, as you can put in Node packages which aren't executable, and then this ToolBase would be useless (without adding some extra flags, options, and shenanigans).
…and mypy ignore
sureshjoshi
added
backend: JavaScript
|
Thanks! I'll bow out in favor of @chrisjrn, who is looking at stuff in this area. |
Cool beans - I added you for those test/query/subsystem shenanigans you just taught me about. I actually don't know which maintainers to add on which languages. Like, not sure who the resident |
Added support for a
versionoption to Prettier and Pyright via anNpxToolBase.Some day in the future, I would like to see Subsystem mixins for this type of common, repeated functionality - but that's a longer discussion.
Closes (#17557)
[ci skip-rust]
[ci skip-build-wheels]