fix(esbuild): prefer finding entry_point files in deps rather than srcs #2692
Conversation
When using esbuild with `js_library`, the entry_point may be part of the deps, therefore the path will end up in `bazel-out/` inside the sandbox where esbuild is running, however the entrypoint path will be in the sources path, leaving any relative path inputs to no longer be relative to the entrypoint file. The reordering here forces the `resolve_entry_point` method to prefer the file that resides in the `bazel-out/` path in the sandbox. A possible future breaking change would be to force users to list the entrypoint file(s) in either srcs or deps for the correct pathing, or remove `srcs` from esbuild, meaning all input files must be in the output tree.
👍 - I often find it confusing when a bundle-type rule has both srcs and deps. I would general lean towards deps but 🤷 |
|
Yeah I agree it can be confusing. The intention was to support where esbuild can take ts sources directly, these would go in I'd also like to support using esbuild without the |
|
A minor hiccup with removing I assume that is |
|
@joneshf I don't think anything would change for you under that proposal other than anything you have in |
…cs (#2692) When using esbuild with `js_library`, the entry_point may be part of the deps, therefore the path will end up in `bazel-out/` inside the sandbox where esbuild is running, however the entrypoint path will be in the sources path, leaving any relative path inputs to no longer be relative to the entrypoint file. The reordering here forces the `resolve_entry_point` method to prefer the file that resides in the `bazel-out/` path in the sandbox. A possible future breaking change would be to force users to list the entrypoint file(s) in either srcs or deps for the correct pathing, or remove `srcs` from esbuild, meaning all input files must be in the output tree.
…cs (bazel-contrib#2692) When using esbuild with `js_library`, the entry_point may be part of the deps, therefore the path will end up in `bazel-out/` inside the sandbox where esbuild is running, however the entrypoint path will be in the sources path, leaving any relative path inputs to no longer be relative to the entrypoint file. The reordering here forces the `resolve_entry_point` method to prefer the file that resides in the `bazel-out/` path in the sandbox. A possible future breaking change would be to force users to list the entrypoint file(s) in either srcs or deps for the correct pathing, or remove `srcs` from esbuild, meaning all input files must be in the output tree.
When using esbuild with
js_library, the entry_point may be part of the deps, therefore the path will end up inbazel-out/inside the sandbox where esbuild is running, however the entrypoint path will be in the sources path, leaving any relative path inputs to no longer be relative to the entrypoint file.The reordering here forces the
resolve_entry_pointmethod to prefer the file that resides in thebazel-out/path in the sandbox.A possible future breaking change would be to force users to list the entrypoint file(s) in either srcs or deps for the correct pathing, or remove
srcsfrom esbuild, meaning all input files must be in the output tree.