Allow for translate_package_lock to store result in the repo about rules_js HOT 1 CLOSED

Doing some design thinking on this:

We can rely on update_source_file pointing to an action that just produces the .bzl content as a regular output, rather than having a standalone program the user invokes with bazel run. Unlike rules_go it means you have testing that the deps.bzl stays up-to-date.

The current implementation is pure starlark, because repository_ctx gives us file read/write. However as an action we need to spawn a process to read the file, so reusing the code is tricky. Options:

• fetch and run a standalone starlark interpreter and run the library code in it
• rely on a python toolchain, and load the starlark helper functions as if they were python code, which works so long as we stub out the starlark builtins
• repository rule is no longer pure starlark, instead calling some helper program which can also be run as an action. Downside is the toolchain isn't available during repository rule execution so it makes that more complex for all users, even if they didn't want to check in the resulting .bzl file
• maintain a port of the same logic in another language like JS that can run in the action

The translate_package_lock rule doesn't just produce the deps.bzl file. It also creates a bunch of aliases in BUILD files in the generated repo, so you can dep on @npm_deps//acorn rather than @npm__acorn-8.5.7//:pkg. The aliases are both shorter, and guarantee you only import your direct dependencies. We'd lose that feature in this usecase.

from rules_js.