Alex Eagle

https://github.com/alexeagle/repro_stackb_py_proto_deps/compare/works shows that when the `strip_import_prefix` is removed, then the `deps` are generated correctly.

one more note, I think if https://github.com/bazelbuild/bazel-gazelle/issues/1173 were resolved, that's probably the principled fix at the right layer, and maybe naturally solves this issue as well. I think @aptenodytes-forsteri is...

Update, we did invent a rules_nodejs-specific rule https://github.com/bazelbuild/rules_nodejs/blob/7f688a95c9002a9e5148f218dfa9f1ea6464f50a/nodejs/private/providers/directory_file_path_info.bzl but would still be better to share this, since it has a Provider symbol that ought to allow interop between rulesets.

Update again, this is now in bazel-lib: https://docs.aspect.build/aspect-build/bazel-lib/v0.9.6/docs/directory_path-docgen.html

More generally this provides a third option for running binaries/tests: 1) only programs with runfiles awareness can be used with Bazel 2) rely on runfiles symlink forest and make windows...

Nothing node specific here, I think we just have more ambitions to run existing test runners under Bazel rather than rewrite everything like java_test et al

rules_nodejs does have an immediate need for this, to unblock usage of arbitrary programs under Bazel on Windows. I'll just copy this code into our repo for now.

That workaround is the same thing we do in rules_nodejs. Expose the rule to stardoc and the macro to users

@srikrsna-buf is just hitting the same issue being discussed in this thread, which is that the distribution of bazel-skylib ships without the gazelle/ directory. (see target `//:distribution` in this repo)...

An approach I don't see on the thread above is to have the `gazelle/` folder be a nested workspace and a separate Bazel module, but have it be released together...