test: add an example of how to invoke Rspack#2846
Conversation
|
|
|
||
| module.exports = defineConfig({ | ||
| entry: { | ||
| main: './rspack_entry.js', |
There was a problem hiding this comment.
So is rspack resolving this from the current working directory or relative to the config file since the config file will live in a separate bazel-out tree than than this entrypoint
There was a problem hiding this comment.
I believe it's resolving it from the current working directory. js_run_binary's working directory is basically "bazel-out/<target platform>/bin/" + chdir where in this case chdir is "rspack".
For the output path below, I did have to replace __dirname with process.cwd() to reflect that the config file is no longer placed in the target platform bin directory.
This example started out as a test case by @jbedard and @nickschaap showing how `js_run_binary` can sometimes fail to work correctly when the execution and target platforms are different. I was able to get it working, primarily by setting `use_execroot_entry_point = False`. The problem with the default behavior (`use_execroot_entry_point = True`) is that it runs target-platform sources during the build action, which can go haywire if the target platform is meaningfully different from the execution platform. Getting all the sources in the right place and built for the right platform is not entirely straightforward, so I thought it would be good to have a simple example showing this. I added a lot of comments trying to explain why everything is set up the way it is.
…tform separation For webpack and rollup invocations, configs and their npm plugin/loader dependencies now live in the tool binary's runfiles rather than being passed as target-platform action inputs. This ensures all exec-platform code runs from the same runfiles tree, avoiding resolution failures in cross-platform builds. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
2 participants
This example started out as a test case by @jbedard and @nickschaap showing how
js_run_binarycan sometimes fail to work correctly when the execution and target platforms are different.I was able to get it working, primarily by setting
use_execroot_entry_point = False. The problem with the default behavior (use_execroot_entry_point = True) is that it runs target-platform sources during the build action, which can go haywire if the target platform is meaningfully different from the execution platform.Getting all the sources in the right place and built for the right platform is not entirely straightforward, so I thought it would be good to have a simple example showing this. I added a lot of comments trying to explain why everything is set up the way it is.
Changes are visible to end-users: no
Test plan