I'm (finally) using Pants in production again and I'm trying to see how far I can get with Pants managing our CI. I'm trying to make sense of the JS backend and see that it needs some work to be a very good tool for our use case, but it seems like some things just plain don't work. Any chance one of the people who've worked on it/deployed it can tell me what features I can expect, and how I can help work on improving things? (ping @broad-processor-92400? @worried-painter-31382)

Without denigrating Tobias’ work at all (amazing to get something going at all), I think it’s very early stages, so I’m not too surprised that things aren’t smooth. In my experiments, I also found it to be very early but haven’t dived in deeper yet due to other pants-y priorities. If we’ve got three of us interested, sounds like it’d be good for me to put some more energy into it too. I’m similar to you, with a typescript code base. Should we have a goal of getting testing working? And then going from there?

(I'll be back to pay attention to this thread in ~2 hours from now)

The test goal works the same as for python backend IIRC, meaning that the source files needed to participate will have to be brought in via dependencies. Dependency inference only really works for vanilla ECMA JS (which typescript doesn't follow 100%), and is also broken atm due to me blanking on parts of the syntax my org does not use. (https://github.com/pantsbuild/pants/issues/19819). I also believe, just like python, the goal only accepts "known" source fields. I think before too much effort go into new and shiny one of the things that need be done is change how node installations/sandboxes are created. The latter part of this comment https://github.com/pantsbuild/pants/discussions/17357#discussioncomment-7200902 is where my head is at at the moment. The piecemeal approach of trying to recurse and install parts of the workspace currently in place doesnt really work with newer versions of the package managers, and some workspace setups do not work atm. Git references are also not supported, and I feel like what really needs to happen there is making external binaries dependable by node scripts, i.e piggyback of

adhoc_tools

goodies. I'm also worried about the reports of processes becoming sad because a file was open / written to / already existed between parallell runs of npm, e.g https://github.com/pantsbuild/pants/issues/20062. Not really related the JS backend work per se, but will probably be a wart showing up there as well.

So at the moment, the #1 thing that would be useful to me would be to just run the existing test script that exists in my

package.json

. Is that doable at the moment?

We use

export ... from ...

so I'm happy to take that one on, and I imagine it'll be a good way for me to start poking at some of the moving parts here. I've assigned #19819 to myself, hope that's okay.

Is there any documentation of what works and how to use that functionality at the moment?

maybe https://github.com/pantsbuild/pants/blob/main/src/python/pants/notes/2.17.x.md#new-javascript-experimental is all we have in terms of docs at the moment?

Ok. So what does "running a test" actually mean? Running a specific JS test file using the

test

script defined in

package.json

?

Running tests means running a test script in package.json with your package manager, yep. There's some configurability exposed via the

node_test_script

build symbol, pants defaults to guessing the "test" script is what you want. Pants has a requirement here that the script should accept file paths as variadic args. Coverage reports and "batching" is supported

FWIW I wrote an internal plugin adding two new targets -

ts_source

and

ts_test

. I was able to use the JS parser OOTB with a couple of rules like this

@rule("Generic rule to infer dependencies of TypeScript targets.")
async def infer_typescript_dependencies(
    request_wrapper: RequestWrapper,
) -> InferredTypeScriptDependencies:
    """Infer dependencies for TypeScript targets."""

and

metadata = await _prepare_inference_metadata(request_wrapper.request.field_set.address)
    import_strings = await Get(
        NativeParsedJavascriptDependencies,
        NativeDependenciesRequest(sources.snapshot.digest, metadata),
    )

The TS code is separate in our repo, so it was well contained and easy to reason about. I only had to add the mapping, what Tobias mentioned before:

path_mapping_digest = await Get(Digest, PathGlobs(["our-ts-code-dir/tsconfig.base.json"]))

@fresh-cat-90827 Any chance you could get a branch up with that plugin included? I'd be happy to help knock it into shape for release

hey @ancient-vegetable-10556 🙂 sorry it took me a while.... Do you think we want to have TypeScript targets in Pants, i.e. those

ts_source

and

ts_test

targets? If so, then of course I could work on the feature - I'll need to clean it up first to remove all the company specific code that doesn't make sense elsewhere. If you can please be patient with me, I'll let you know when I have something. If you'd be able to review and help that would be awesome of course, many thanks for the offer!

Yes, we definitely want typescript source and test targets in Pants, and I'll be using them the moment they're available. I'm happy to help with cleanup, testing, feedback