Bazel always runs executables at execRoot (see https://docs.bazel.build/versions/master/output_directories.html)
Even in a directory with nested packages, you would need only point webpack to the right entry point within the nested directory structure. This can be accomplished using webpack's --entry flag or via the entry configuration option within your webpack config. It might be worth showing an example of how to run webpack in a nested package using vanilla bazel rather than a wrapper script

In general, I think you want to run under execroot rather than changing the current working directory so that file watching is easier for the webpack process

So this is a weird example because I ported it form internal code where the --run_under shifts the directory into a nested directory. This removes the need for subprocesses like webpack to have special paths past to them. I think the problem I'm trying to solve for here is that a lot of JS tooling assumes the cwd is where the project is. That's not true with Bazel, and thus makes setting things up kind of fragile. I'd rather meet the tooling where it currently is, than make the tooling meet Bazel where it is.

I'm not following how the execroot is better for the underlying file watcher. Wouldn't watching more unnecessary files be more expensive for webpack instead of only watching the files it is concerned with?

Dont you want "ibazel_notify_changes", here so that ibazel won't restart the devserver process?

Yes I need to add that. The one issue I hit on Friday was that ibazel for some reason invokes the process in a way that doesn't allow it to receive fs events, thus webpack-dev-server won't respond to files being modified. I haven't dug into why this is the case yet. But the example above (though it doesn't provide the rebuild benefit that ibazel would provide, it does allow the dev server to respond to file changes in the run tree.