Q re: Typescript/Javascript support (recalled want...
# general
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
(yay Go),
(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
is currently a plugin,
should be added in (and can be added in, if not already there) - so we've started on the
stories) and then we're stuck with the question of transpiling/bundling (
). For instance, my internal tooling moved from
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
to yet another transpiler/builder (since the JS ecosystem is the wild west), is a non-starter for me.
cc @happy-kitchen-89482 @witty-crayon-22786 for higher level perspective on Pants' role in that backend
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
❤️ 2
cc @happy-kitchen-89482 @witty-crayon-22786 for higher level perspective on Pants’ role in that backend
thanks!: will review in a little bit.
👍 1
Looking at the Python backend, Pants uses
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
backend compile on it's own, or rely on `cmake`/`make`/`ninja` Right now, it compiles each file to a cached object with the
clang compiler
and then links those to a cached binary
I think this discussion is more about drawing lines in the sand of a (my) mental model for the Pants role
👍 1
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
The purpose should be: 1) provide a uniform interface, 2) ability to build a JS bundle and package it as an asset into a pex, 3) perf improvements where feasible
Into a pex?
That's to serve up a UI from a Python webserver I think.
Basically, slurp the compiled app as a resource into the PEX.
A pretty tangential goal unless you have Python goggles on.
Ah, okay 🙂 I got so confused for a sec
heh.. 😛 (I really do have a use for packaging some front end into a pex.. 😄 )
👍 1
I see a
./pants package :something && ./pants deploy :somethingelse
being my primary workflow ... Oh wait, I guess this would just be
./pants deploy :somethingelse
and let the magic take over
For “pex” also read “docker image” or whatever
👍 1
./pants package :something
should also be able to build the assets embedded in that something, such as JS bundles
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 🙂
🎉 2
🙂 1