https://pantsbuild.org/ logo
Join Slack
Powered by
I'm having a foggy time mapping out simple Typescr...
# plugins
b
I'm having a foggy time mapping out simple Typescript support just to run 
eslint
initially. 1. Declare and use 
npm
as an 
ExternalTool
. That's easy-peasy. 2. We need a cached 
node_modules
per `package.json`/`package-lock.json`. Seems like I could have 
NPM.config_request
which will return those given a set of sources. (But this I don't think is right, since each "config" makes one unique 
node_modules
🤔 ) a. This should be easy-ish with a rule with a 
Process
and input/output digest for relevant files. The process runs 
npm install
in the right working dir. 3. Once I can request and access 
node_modules
running ESLint from it's 
.bin
dir should be easy. I think this is easy as well. So I think just 2 is foggy since each config kind of makes a "hard wall" between 2 sources 🤔
👀 1
f
Would it help if 
Process
had a way to symlink in the 
node_modules
directory already in the repository?
(This could be like immutable inputs but for large sets of data managed by other tools.)
(Also, the management of 
node_modules
has similarities to Go 
vendor
directories and other large sets of data downloaded as a result of a lockfile / consistent resolution. If Pants manages those, then it has to realize that data into sandboxes which has been a problem in the past for us with large sets of data, e.g. the Go SDK)
b
I dont think the size is an issue, so much as the duplicity when devs need outside-of-pants support (like IDEs). For my little PoC here I don't think I have much a preference. The only delineating factor is that if Pants fully manages this, it's much easier to write CI code. (Most Python devs dont have node modules in the dirs, so ideally CI doesn't try and set it up. If Pants managed 
npm
and 
node_modules
, the relevant code only fires when we try to run 
eslint
, which is only the case if devs touched one of those (due to 
--changed
))
node_modules
isn't dissimilar to Python's venvs either. This actually kind of feel like a "multiple resolves" feature 🤔
@hundreds-father-404 how difficult is it to hack together an automatically-discovered-multiple-resolves feature for a new language?
c
There can be a considerable amount of data in 
node_modules
, and I think we’d do well to avoid copying it around, or worse, re-build it too often…
Copy code
$ du -sh node_modules/
998M	node_modules/
$ find node_modules/ -type d | wc -l
   15326
$ find node_modules/ -type f | wc -l
  112682
➕ 1
b
Oh I agree completely. But this isn't any different from a Python venv. It'd be cached from Pants PoV and if devs want to make their own no one can stop them
I just need a way to have one for each project. I also have seen this request for Python too. To put it in Python terms, each dir with a requirements.txt has its own resolve
c
Ah, right.
h
I'll try to think more about this in a bit, but re multiple resolves, it might relate to https://github.com/pantsbuild/pants/issues/13114
re needing to access the contents of 
node_modules
, https://github.com/pantsbuild/pants/issues/13390 might be instructive as well with what we do for Go. Notably, we extract the subset of 
GOPATH
eagerly so that you only materialize the specific package you need, not the whole chroot every time. I'm not sure that's as feasible w/ JS/TS given their different compilation model. Go is awesome that you convert a dir of 
.go
files into a single 
__pkg__.a
file then all you have to do is pass that one file around
b
Seems theres more to this than meets the eye 😅
h
I do think this question #2 is really the trickiest part of getting JS/TS support! Once it's solved, I hope that doing the rest would be somewhat mechanical Another angle you could try is if it's possible to download Prettier & ESLint as pre-built binaries? Even if you have to host those yourself for now? Iirc Prettier distributes one
b
Yeah, I think I'll take the "eject button" option and hack it all together
⏏️ 3
c
really happy you’re tackling this, @bitter-ability-32190 🙂
b
Well you won't be as what I'm doing is essentially just going to be downloading the relevant tools out-of-band from anything that resembles actual JS/TS ecosystem and running them ad-hoc 😅
c
I can play guinea pig for you too..
ah, it’s a start of something, y’ll see 😛
💯 1
❤️ 1
h
I do think if we can get Prettier & ESLint support going, that's worth shipping as an experimental JS backend - so useful to run 
./pants fmt ::
and run everything
❤️ 1
w
@bitter-ability-32190 Are you working on this in a public fork/repo anywhere? I know someone who might be interested in looking around.... ... ... and yes, it's me
❤️ 1
Oh, I might also have 
eslint
checks and/or 
prettier
formats sitting around somewhere from a test a few months back. Didn't really occur to me that they would constitute a reasonable starting point for a plugin. My brain goes compile-first, everything else later (or never)
May have been 
tsc
checks actually, can't recall if I made it to 
eslint
because eslint has so many ways to be consumed, and ignore files, and whatever else. Was a mild mess
b
Not public (yet), although I think I'm having to switch gears at work. We'll have to see. But yeah if you have a starter kit please share :)
👍 1
6 Views
Open in Slack
PreviousNext
Powered by