As per https://github.com/pantsbuild/pants/issues/14190 What should I be planning to name the top-level language packages and targets for experimental JS and TS + PrettierJS support? In my repo, I've used

nodejs

- which is a runtime, not a language. https://github.com/sureshjoshi/pants-plugins/tree/main/pants-plugins/experimental/nodejs I see that for JVM runtimes, we have separate Scala, Java, and Kotlin packages - so I could do javascript and typescript, but that feels boilerplatey - since one is basically a superset of the other. For C, we have the

cc

package to represent both C and C++, which both compile down to machine code, but use different(ish) compilers and have different language specifications. I chose

nodejs

only because I pull that down to handle installing and running deps, so it made sense to me - but might not make sense in the larger ecosystem? https://github.com/sureshjoshi/pants-plugins/blob/main/pants-plugins/experimental/nodejs/subsystem.py Finally, if there is general indifference at the moment, and since this will be experimental - I can use

nodejs

- because that requires the least effort to get something up and running

Looking ahead I would call it

javascript

? I think typescript still counts as part of that ecosystem, and probably doesn't need a separate plugin

I encourage us to use Rescript to inform this decision: https://rescript-lang.org Not that we will necessarily support Rescript. But what naming would put us in a good position for Rescript, or the next JS-adjacent language to come along every 6 months hehe? I generally bias more towards

js_sources

and

ts_sources

(or verbose if necessary), rather than combining them

I can use those sources a the target level, since the

ts_sources

would need to have

tsc

run over them to compile down to JS at some point. I hadn't gotten to compilation yet, so my generic

node_sources

was enough. What about the top-level packaging?

pants.backend.experimental.???.lint.prettier

I was the main person to advocate splitting the JVM backends into those 3, unlike v1. With the reasoning that if I'm pure Java, I don't want all this clutter about Scala showing up! Even though TS is extremely popular, it's still possible and common to be JS only

Ah okay. I see what you mean. I'm gone for a few hours, but when I come back, I'll dig into how eslint and the like treat typescript. I think they use plugins, if memory serves.

Yeah they do

Hmm, maybe Typescript as a

./pants check

plugin makes sense. Runs though, compiles, etc.... Or at least, however else we handle/plan to handle compilers (on interpreted languages)

I think ts and js are more tightly bound than Java and Scala, but I'm not opposed to a separate backend if only for "marketing" purposes

Step 1: https://github.com/pantsbuild/pants/pull/15442

+1 on having typescript as a sibling backend to javascript, although the implementation can be shared (much like how experimental backends are implemented)

@curved-television-6568 By sibling, are you referring to there being a

pants.backend.javascript

AND

pants.backend.typescript

?

Yep, so per your observation, that if you see

pants.backend.javascript

you’d then look for

pants.backend.typescript

or suspect it isn’t supported, rather than baked into the javascript backend.

Roger. And in that case, how would you place plugins that can be used on either (prettier, eslint, etc)? Would you nest under one namespace, or the other, or both?

Implement once, but those that work for either, register them from each, so regardless of which you enable, you get them.

I see, that's an interesting idea - basically aliased. The implementation of this will probably come up in a week or two, so good to get ideas forming on it.

Inspiration is from how experimental backends are developed, in place as they would if they weren’t experimental, only the registration part is added under the experimental tree.. so migration is simply moving the register.py file… kind of.

For tools that work for both, I would bias towards putting in

pants.backend.javascript

. I think it will be fairly obvious to TS users that it's ~superset of JS, so makes sense to have to activate a JS tool My two cents is that a pure JS dev should have zero noise from TS