Q re: Typescript/Javascript support (recalled wanting to ask about this on the monthly meeting last week). Will probably raise this as a GH discussion too. What would Pants's "purpose" be in TS/JS support? Would the idea be to be: A) a replacement for stuff like

webpack

,

vite

,

esbuild

(yay Go),

swc

(yay Rust), etc (to which I'm a giant 👎 ) - or, B) would it be to use those as plugins and facilitate their usage in a consistent matter, and maybe throw some dep inference + caching in for good measure, or C) Alternative/middleground

prettier

is currently a plugin,

eslint

should be added in (and can be added in, if not already there) - so we've started on the

fmt

and

lint

(and

fix

stories) and then we're stuck with the question of transpiling/bundling (

check

,

package

). For instance, my internal tooling moved from

experimental_shell

to a ViteJS plugin which uses all of my existing configuration (and, more importantly, plugins for Svelte/Kit) and basically calls the correct vite args at the command line. The prospect of using Pants and migrating config from

vite

to yet another transpiler/builder (since the JS ecosystem is the wild west), is a non-starter for me.

As a customer, I think its probably B. 1. I'd like to be able to use prettier, other tools the same way I do for my python tools (pants fmt). 2. I'd like to have something to use with npm/yarn/webpack to do dependency management and caching. That said, I hadn't realized quite the extent that the JS ecosystem had fractured until yesterday's Turbopack announcement I definitely don't think its A. There's enough choice in the JS ecosystem without rebuilding the wheel here

cc @happy-kitchen-89482 @witty-crayon-22786 for higher level perspective on Pants’ role in that backend

thanks!: will review in a little bit.

Looking at the Python backend, Pants uses

black

mypy

flake8

etc and just wires it all up, so I think that matches alt B.

It's a little bit more convoluted, as those are fmt/fix plugins, which we would/could/can split out. I guess the canonical Pants equivalent would be... Umm, like... transpile TS to JS and cache that result until it changes. And then strip/obfuscate, and cache that. And then bundle all the JSes together, and cache that result (like, custom intermediate steps - rather than forking EVERYTHING to some 3rd party tool). The loose-equivalent would be having the

cc

backend compile on it's own, or rely on `cmake`/`make`/`ninja` Right now, it compiles each file to a cached object with the

gcc

or

clang compiler

and then links those to a cached binary

Similarly as a customer, I think having good support for B is important, even if pants eventually does A too (because it gives better caching/faster builds/ whatever). I suspect B gives a fast path for exisiting monorepos to adopt pants fully, and, as you've observed, the JS/TS ecosystem seems pretty… diverse. In addition, there's lots of language specific functionality built into the bundlers (often as plugins), like fine grained treeshaking, CSS support (eg tailwind parses all the JS files to work out which classes need to be included), live reload integrated with the browser, and others. Thinking about our team, I suspect it'll be a hard sell for front end engineering to switch away from that normal JS/TS tooling, at least until pants has proven itself. I suspect pants only prove itself convincingly via B (ie running outside pants gives the same behaviour as running inside) or a relatively extensive A.

I think the idea that Pants should not get in the way is a good one. As much as possible it should just run your tools for you, not prevent you from using your tools. Basically, you should feel ~comfortable in a --keep-sandboxes chroot even if you don't know Pants.

A GH discussion would be good, but I think B

Into a pex?

That's to serve up a UI from a Python webserver I think.

Ah, okay 🙂 I got so confused for a sec

heh.. 😛 (I really do have a use for packaging some front end into a pex.. 😄 )

Migrating: https://github.com/pantsbuild/pants/discussions/17357

For “pex” also read “docker image” or whatever

High level, barring any drastic comments in the GH discussion, looks like I'm in a position to starting working on merging my internal vite plugin and TS/JS work 🙂