javascript: Add an explicit npm_distribution target instead of coupling to node_package

[tobni]

The coupling of node_package (generated from the package_json target) with the package goal caused some unwanted side effects when trying to integrate with other backends, docker to be exact.

Because of the way the dependency graph is constructed between in-repo nodejs packages, this caused package:able targets to always be included.
See this bit of code:

pants/src/python/pants/backend/docker/util_rules/docker_build_context.py

Line 280 in f95ed94

embedded_pkgs_per_target_request = Get(

The transitive dependencies of the docker_image currently causes packaging of workspace packages, even though you probably do not want to include the resulting tarballs at all.

Even worse, some package manager + workspace combinations are flat out broken, see pnpm/pnpm#4351.

This solution "moves" the package:able target out of the dependency graph by placing it as standalone thing, outside of the automagically constructed dependencies.

Fixes #18922
This PR does not provide a work-around for the linked PNPM issue.

[stuhood]

@kaos : Thoughts on whether the docker backend's dependencies should be transitive like this?

@tobni : Independent of the issue of transitivity in consumers, do you think that you still prefer this interface? Or would it make more sense to try and change the behavior of the consumer?

[tobni]

I do prefer this interface change regardless.

[stuhood]

@tobni : For future reference:

Addresses #18922

If you change this to "Fixes #18922" or "Closes #18922", the mentioned ticket will close automatically when the PR does.

[kaos]

@kaos : Thoughts on whether the docker backend's dependencies should be transitive like this?

@stuhood sorry, not following what you are referring to as different in the Docker backend?

Edit: ah, I looked at the code, now I see the disussion in the PR description, reading up on that...

Edit2: right, think I get it now. Meaning, that perhaps the docker backend should only work on direct dependencies, not transitive, which would've also avoided this issue. I think that could make sense, but would rule out the use of things like grouping a set of packageables using target for instance in order to reduce BUILD file duplications. But that's a rather hypothetical argument..