Add support for explicitly specifying node entrypoint location

[dastbe]

Describe the feature

Similar to how one can specify the runtime via JSII_RUNTIME, there should also be support for providing an explicit location for the node entrypoint with fallback to searching the path.

Use Case

For my particular use case, I'm writing bazel rules to handle executing cdk apps written in arbitrary languages. In this case, manipulating the path to ensure the correct node entrypoint is present and has the correct priority is problematic and non-standard across language_binary targets. By comparison, having an explicit environment variable for setting the node entrypoint would be straightforward to support.

Proposed Solution

Add a JSII_NODE environment variable option to specify the exact location of the node entrypoint. if unset, fallback to existing behavior of environment lookup.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.55.0

Environment details (OS name and version, etc.)

mac/linux

[dastbe]

I've created #3890 to demonstrate how this will work for go. If you're down with this approach I can implement the remaining runtimes.

[RomainMuller]

Is this not the same as ensuring the "correct" node is the 1st in $PATH?

[dastbe]

In normal cases, yeah. However, with bazel (and go) there are complexities

1. bazel prefers away from putting things on the path. You can work around this by using the run_shell command and constructing the path as part of the shell script, but including arbitrary binaries (i.e. a go cdk app, a js cdk app, a c# cdk app, etc.) becomes more difficult as you need to handle more environment setup compared to the more straightforward run command for a binary target. Since this environment setup can vary by the binary type, you possibly have to do incremental work for every cdk language.
2. bazel prefers using relative paths as it uses a combination of symlinks and sandbox directories depending on the platform. go in particular no longer supports relative path lookups. You can again hack around this as part of a run_shell command, but see above why run_shell is complicated to use when you have multiple kinds of binaries you can support.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.