Hey! I'm looking for some info on the future of pa...
# general
Hey! I'm looking for some info on the future of pants support for web dev - specifically for people developing React apps. Can anyone fill me in or point me at some documentation?
šŸ‘€ 1
I don't know what else is out in the world, but I was possibly going to look into implementing a sort-of "poor-man's" support since we have a react app and a NodeJS app in our repo. Format would be easy to model/ execute, for lint and test I was going to just grab all files as one big input (so I don't have to do any dep inference)
I should add, this would be in a plugin outside of the Pants repo
šŸ‘ Thank you! I think a large part of our devs frustration comes from waiting for webpack and repeatedly having to cd into project directories to run npm commands.
āž• 1
I can't say the end result of my work will be that helpful to you then. Really the hole I'm trying to plug is out-of-Pants commands in our CI. My hole-plugging will essentially just taking the commands being run outside of pants and running them in-pants. So I suppose point #2 will be solved, but likely not 1.
@dry-analyst-73584 if you haven't already participated in the annual community roadmap survey, please do put requests in there asap. @witty-crayon-22786 is preparing to close submissions shortly, to switch to voting. It would be really good to have your suggestions in there, since webdev is a niche we'd love to be serving better and crucially need users' insights into how.
āž• 3
As it happens we also are very interested in better understanding specifics of what Pants JS support should look like, given the number of monorepo build tools that exist in that ecosystem...
Not sure if it's of any help @dry-analyst-73584 but since NPM and Yarn are pretty full fledged, stable tools, what I end up doing is (with my Vite + React project), doing a
yarn build
and then I have Pants targets that grab those files and package them for transfer or deployment to a Docker container.
Copy code
    sources=["build/**", "config.json", "Dockerfile"],

I wrote that before the Docker target was around, so I need to update. Otherwise, I think you can use a Shell target to actually initiate the build process... Not sure if that's helpful or not - just what my existing-ish workflow is
Do you have a link for the roadmap survey?
Thanks SJ! That is really helpful. I'm in the process of surveying our web people about what their development process looks like right now. It kind of seems like everyone has made it up as they go along and no one is particularly happy with what they've got.
NP - one question I'd be curious about is whether it's related to development or deployment workflows. When I've developing, most of my time I'm just sitting in
yarn dev
with some mocking tools running in other terminals. I used Pants specifically for a deployment workflow, which was otherwise a set of ugly bash scripts
(maybe relatedly: wanted to make sure you had all seen @curved-television-6568ā€™s work on https://www.pantsbuild.org/docs/run-shell-commands. it allows you to formalize some of the scripting that might be involved here in the absence of native support)
šŸ‘€ 3
We'd love to have a suggestion for JS/React/web dev support to vote on
One reason we haven't done it yet is lack of a design partner with driving use-cases
That makes sense. I haven't done enough web dev myself to have strong opinions on what should be supported, but I have done enough to know that the current tooling is painful. I'll see if I can solicit some more feedback from more of the web team.
Benjy that survey link isn't working for me
Yeah, also a github issue with a description of what your web team would like to see would be super helpful. With JS support the complexity is not in actually writing it, but in designing it to meet user needs, since the JS ecosystem is so rich and fragmented
@happy-kitchen-89482 Are there any existing policies about what should be handled by Pants/Python solo - vs what can be forked off to a 3rd party dependency which is expected to be installed? Docker's a good example, because the plugin basically handles and manages dockerfiles and config and the like, but the packaging/running gets appropriately forked out to the Docker daemon (ditto for shell). Like, is it a reasonable expectation that something like NPM/Yarn are installed as a pre-req to any JS/TS story? They're package managers, rather than runtimes - but also tightly ingrained and basically mandatory. So, simplest example, I have a project with a package.json which has scripts defined, and a Pants target would call said scripts? Or require that certain scripts exist for building, packaging, linting, formatting?
That's a great question. It can go either way. Basically if it's hard or unreasonable to install automatically, we expect it to be present. Otherwise we prefer to install it ourselves.
For example, Pants doesn't install Python interpreters for you, and expects them to be on the PATH, but it does install all other python tools (pytest, for example). Similarly it doesn't install Docker itself, but it does install hadolint. On the other hand it does install JVMs.
So when it comes to NPM/Yarn, I think our first preference would be to install it ourselves, so we can control the version
āž• 2
As long as it's not terribly hard to do so
And then Pants goals like linting, formatting, testing, packaging would be invocations into the known commands in NPM/Yarn
At least that is my thinking, but I am not an expert on JS tooling
That seems like a reasonable line to me
Ah, okay, great - thanks for the info. My work requires me to work across a lot of programming languages/build tools - and there always ends up being this weird middle ground where build tools just don't/"can't" overlap, so I fall back to shell scripts. Using one tool as a facilitator would be nice, but I like the idea of delegating compilation/building to their native or de facto build tools, if possible. I feel that follows the rule of least surprise over the duration of long projects and leads to easier workarounds if there is a bug along the way. Python + JS/TS is a pretty natural overlap in terms of server/client work - but I've ended up needing to handle them separately, even though they're deployed together. Mildly infuriating.
āž• 1
I think the most accurate comparison here would be if Pants installed pip, or poetry. Those I'd say are closer to npm/yarn Or if Pants did Rust, cargo
I completely prefer Pants to be controlling these too. Makes tool drift minimal.
āž• 3
Actually, @happy-kitchen-89482 if Pants turns into Rust-embeds-Python and is shipped standalone, could it then be used to install Python? (A la pyenv or similar)
šŸ’” 1
Oh and I guess I didn't say. I'd be willing to chime in on JS/TS support as well ā¤ļø
ā¤ļø 2
I'd be willing to take a crack at a proof-of-concept plugin - I need a better way to run python and yarn build commands while generating my blog, and right now it's more manual than I'd like to admit šŸ™‚
šŸ˜… 1
Yeah, on the whole we would prefer Pants to install its own underlying systems and tools. And it could install Python interpreters by delegating to pyenv or asdf for example. That work just hasn't been done yet.
So we do want Pants to delegate to the standard tooling, such as NPM/Yarn, but it would be preferable if Pants installed those for its own use, rather than rely on some system one existing.
šŸ‘ 3
That's precisely what motivated us adding Shell support. We were using Shellcheck for pantsbuild/pants but not via Pants, and local developers had a different version than CI so were confused by the issue. Thus: https://blog.pantsbuild.org/introducing-pants-2-5/