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?

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)

👍 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.

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.

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.

files(
    name="deployment",
    sources=["build/**", "config.json", "Dockerfile"],
)

archive(
    name="client-app",
    files=[":deployment"],
    format="tar.xz",
    output_path="client-app.tar.xz",
)

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?

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)

Survey is here: https://pantsbuild.slack.com/archives/G0107QFGGAW/p1642094759014800?thread_ts=1641339469.036500&cid=G0107QFGGAW

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.

Thanks!

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.

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.

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'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 🙂

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.

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/