What happened?

Options for the esbuild rule only allow for truthy source map options, there is no way to disable source maps.

Code in question:

Version

Development (host) and target OS/architectures:

Output of bazel --version:
bazel 5.1.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:

http_archive(
    name = "aspect_rules_esbuild",
    sha256 = "1e365451341ffb2490193292dfd9953f2ca009586c2381cb4dc08d01e48866b7",
    strip_prefix = "rules_esbuild-0.12.0",
    url = "https://github.com/aspect-build/rules_esbuild/archive/refs/tags/v0.12.0.tar.gz",
)

Language(s) and/or frameworks involved:

How to reproduce

No response

Any other information?

Source map omitted on the command-line shows no map is generated

>>> pnpm exec esbuild foo.js
console.log("Hi");
>>> pnpm exec esbuild --sourcemap foo.js
console.log("Hi");
//# sourceMappingURL=data:application/json;base64,ewogICJ2ZXJzaW9uIjogMywKICAic291cmNlcyI6IFsiZm9vLmpzIl0sCiAgInNvdXJjZXNDb250ZW50IjogWyJjb25zb2xlLmxvZygnSGknKTtcbiJdLAogICJtYXBwaW5ncyI6ICJBQUFBLFFBQVEsSUFBSSxJQUFJOyIsCiAgIm5hbWVzIjogW10KfQo=


>>> pnpm exec esbuild --outfile=foo_bundle.js --bundle foo.js

  foo_bundle.js  48b

⚡ Done in 13ms

/// (Confirmed no .map file generated)

Potential implementation: missing sourcemap option should not produce a source map or setting sourcemap to False

Fund our work

• Sponsor our open source work by donating a bug bounty

Since we turn preserveSymlinks off so that node_modules resolution works with the rules_js symlinks node_modules tree, esbuild will currently leave the sandbox by following symlinks. The rules_js node fs patches don't apply to the golang binary. There is currently no hook in esbuild where we can customize module resolution so that esbuild stays in the bazel sandbox.

If bundling .js files that come from transpiled sources, it is currently recommended to set the following configuration

config = {
        "resolveExtensions": [".js"],
    },

so that esbuild doesn't pick up and re-transpile the .ts sources it can find outside of the sandbox and seems to prefer (#57 (comment)).

What happened?

This rule doesn't correctly track dependencies change. I renamed a file from src/Util.ts to src/util/index.ts and it failed to build.

Version

Development (host) and target OS/architectures: : Rock Linux 9.1 (Blue Onyx) x86_64

Output of bazel --version: 6.2.0

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: Indicated in the provided link of the repo

Language(s) and/or frameworks involved: JavaScript, TypeScript

How to reproduce

I have this repository to reproduce https://github.com/Exegetech/buggyesbuildproject

Any other information?

No response

What is the current behavior?

It seems that if output_dir is true, a directory artifact is declared using the rule name as the folder name.

Describe the feature

I was surprised that when I defined output = "dist" with output_dir = True, that the rule would fail with “The following files have no generating action: .../dist". After digging into the code, it seems that name is used for the folder name. Is that intentional?

What happened?

Trying to set esbuild's log level to attempt to debug a module resolution issue, but no matter what I set in the config, it doesn't seem to apply. Example:

esbuild(
    # ...

    config = {
        "logLevel": "debug",  # ignored
    }
)

Version

Development (host) and target OS/architectures: MacOS Monterey

Output of bazel --version: 6.1.1

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: [email protected]

How to reproduce

No response

Any other information?

No response

What happened?

I see at https://registry.bazel.build/modules/aspect_rules_esbuild that the latest version is 0.14.0, but at https://github.com/aspect-build/rules_esbuild/releases I see newer version 0.14.2

Version

N/A

How to reproduce

No response

Any other information?

No response

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency io_bazel_stardoc to v0.5.3
• chore(deps): update dependency rules_nodejs to v5.6.0

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency bazel_gazelle to v0.27.0
• chore(deps): update dependency bazel_skylib to v1.3.0

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

What happened?

When upgrading from 0.13.6 to 0.14.0 the following error is produced

ERROR: Traceback (most recent call last):
        File "/usr/local/home/mrmeku/depot/src/stairwell/WORKSPACE", line 786, column 28, in <toplevel>
                esbuild_register_toolchains(
        File "/usr/local/home/mrmeku/.cache/bazel/_bazel_mrmeku/0fd53cc9eeb7aea8d7b8b30c5522fa8c/external/aspect_rules_esbuild/esbuild/repositories.bzl", line 116, column 15, in esbuild_register_toolchains
                npm_import(
        File "/usr/local/home/mrmeku/.cache/bazel/_bazel_mrmeku/0fd53cc9eeb7aea8d7b8b30c5522fa8c/external/aspect_rules_js/npm/npm_import.bzl", line 631, column 13, in npm_import
                fail(msg)
Error in fail: Invalid npm_import parameter 'register_copy_directory_toolchains'

Version

Development (host) and target OS/architectures:

Output of bazel --version:

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:

Language(s) and/or frameworks involved:

How to reproduce

Just try to build anything which depends on the esbuild toolchain to trigger the error

Any other information?

No response

Fund our work

• Sponsor our open source work by donating a bug bounty

What is the current behavior?

The default node toolchain is used.

Describe the feature

Specify a custom node toolchain similar to js_binary and similar rules.

I'm porting an existing React app to Bazel and rules_esbuild. Before, I was bundling with the following command.

esbuild app.tsx --bundle --minify --sourcemap --target=es2020  --outfile=out.js

app.tsx imports the following libraries:

import { ConnectError } from "@bufbuild/connect-web";
import React, { useEffect, useState} from "react";
import ReactDOM from "react-dom/client";
import {
    BrowserRouter,
    Link,
    Route,
    Routes,
    createRoutesFromChildren,
    matchRoutes,
    useLocation,
    useNavigate,
    useNavigationType,
    useParams,
} from "react-router-dom";
import * as Sentry from "@sentry/react";
import { BrowserTracing } from "@sentry/tracing";

Sentry.init({
  dsn: 'https://[email protected]/zzz',
  debug: true,
  integrations: [
      new BrowserTracing({
          routingInstrumentation: Sentry.reactRouterV6Instrumentation(
              React.useEffect,
              useLocation,
              useNavigationType,
              createRoutesFromChildren,
              matchRoutes,
          ),
      }),
  ],
  tracesSampleRate: 1.0,
});

const SentryRoutes = Sentry.withSentryReactRouterV6Routing(Routes)

function App() {
  return (
    <div className="App">
      <h1>Welcome to React Router!</h1>
      <SentryRoutes>
        <Route path="/" element={<Home />} />
      </SentryRoutes>
    </div>
  );
}

function Home() {
  return (
    <>
      <main>
        <h2>Welcome to the homepage!</h2>
      </main>
    </>
  );
}

const elem = document.getElementById("root")
if (elem) {
  const root = ReactDOM.createRoot(elem)
  root.render(
    <React.StrictMode>
      <BrowserRouter>
        <App />
      </BrowserRouter>
    </React.StrictMode>
  );
}

I've successfully reproduced this bundle with the following BUILD file

load("@npm//:defs.bzl", "npm_link_all_packages")
npm_link_all_packages(name = "node_modules")

load("@aspect_rules_esbuild//esbuild:defs.bzl", "esbuild")

esbuild(
    name = "lib",
    entry_point = "app.tsx",
    output = "out.js",
    target = "es2020",
    minify = True,
    srcs = [
        "app.tsx",
    ],
    metafile = True,
    deps = [
        "//frontend:node_modules/@bufbuild/connect-web",
        "//frontend:node_modules/@sentry/react",
        "//frontend:node_modules/@sentry/tracing",
        "//frontend:node_modules/react",
        "//frontend:node_modules/react-dom",
        "//frontend:node_modules/react-router-dom",

        # Transitive deps 
        "//frontend:node_modules/@babel/runtime",
        "//frontend:node_modules/@bufbuild/protobuf",
        "//frontend:node_modules/@sentry/browser",
        "//frontend:node_modules/@sentry/core",
        "//frontend:node_modules/@sentry/hub",
        "//frontend:node_modules/@sentry/utils",
        "//frontend:node_modules/history",
        "//frontend:node_modules/hoist-non-react-statics",
        "//frontend:node_modules/react-is",
        "//frontend:node_modules/react-router",
        "//frontend:node_modules/scheduler",
    ],
)

I would have expected the build to work without the transitive dependencies, like so:

load("@npm//:defs.bzl", "npm_link_all_packages")
npm_link_all_packages(name = "node_modules")

load("@aspect_rules_esbuild//esbuild:defs.bzl", "esbuild")

esbuild(
    name = "lib",
    entry_point = "app.tsx",
    output = "out.js",
    target = "es2020",
    minify = True,
    srcs = [
        "app.tsx",
    ],
    metafile = True,
    deps = [
        "//frontend:node_modules/@bufbuild/connect-web",
        "//frontend:node_modules/@sentry/react",
        "//frontend:node_modules/@sentry/tracing",
        "//frontend:node_modules/react",
        "//frontend:node_modules/react-dom",
        "//frontend:node_modules/react-router-dom",
    ],
)

This is indeed how it works for ts_project from rules_ts:

load("@npm//:defs.bzl", "npm_link_all_packages")
npm_link_all_packages(name = "node_modules")

load("@aspect_rules_ts//ts:defs.bzl", "ts_project")

filegroup(
    name = "srcs",
    srcs = glob(["*.ts"]),
)

ts_project(
    name = "typecheck",
    srcs = [":srcs"],
    tsconfig = "tsconfig.json",
    deps = [
        "//frontend:node_modules/@bufbuild/connect-web",
        "//frontend:node_modules/@bufbuild/protobuf",
        "//frontend:node_modules/@sentry/react",
        "//frontend:node_modules/@sentry/tracing",
        "//frontend:node_modules/@types/react",
        "//frontend:node_modules/@types/react-dom",
        "//frontend:node_modules/react",
        "//frontend:node_modules/react-dom",
        "//frontend:node_modules/react-router-dom",
        "//frontend:node_modules/typescript",
    ],
)

Would love to know if I'm doing something wrong or this is a limitation of the current rules_esbuild .

What is the current behavior?

No response

Describe the feature

I'm not sure if these rules support bzlmod. If they do, could you update the documentation with instructions on how to use it similar to rules_js?

Fund our work

• Sponsor our open source work by donating a feature bounty

What is the current behavior?

Not sure how to use --loader option, e.g. --loader:.svg=text

Describe the feature

Allow users to set --loader:.svg=text

Fund our work

• Sponsor our open source work by donating a feature bounty

What happened?

Given this:

esbuild(
    name = "bundle",
    entry_points = ["src.js"],
    srcs = ["src",],
    platform = "browser",
    format = "esm",
)

I would expect the output to be an ESM bundle for the browser. However, to get that either entry_points needs to be changed to entry_point, or splitting = True needs to be set. Without either of those the output is an IIFE.

Having a look at the bundle.args.json file for the above I see that format is excluded (which explains why esbuild defaults to IIFE). When I change entry_points to entry_point, or include splitting = True it's in the args, and set to esm. I see that the defaults are documented, but it also seems unusual that I have to set splitting to true to get anything besides an IIFE given direct use of esbuild allows setting of format independently of other properties.

I'm wondering:

1. If format is going to be ignored in the case above, is it possible to emit a warning or notice?
2. esbuild used directly allows you to set format independently of platform, target, and whether you're using entry_point or entry_points. Is that possible here?

Version

Development (host) and target OS/architectures:

Output of bazel --version: 6.0.0

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: rules_esbuild-0.13.5

Language(s) and/or frameworks involved: N/A

How to reproduce

See above :)

Any other information?

No response

Fund our work

• Sponsor our open source work by donating a bug bounty

What happened?

#160 added a JavaScript plugin.
Users report on Slack that this new feature in 0.18.0 increases bundling times by an unacceptable amount.

Maybe it can simply be optimized.
Or it could use the esbuild Go API instead if someone has the time to evaluate that and re-write it.

Setting https://github.com/aspect-build/rules_esbuild/blob/main/docs/esbuild.md#esbuild_bundle-bazel_sandbox_plugin to False is the workaround, though it reverts to earlier behavior of non-hermetic esbuild sometimes not picking up changes.

Version

0.18.0

How to reproduce

No response

Any other information?

No response

What is the current behavior?

Currently when enabling either splitting or multiple entry-points then output_dir = True is enabled.

This is actually only necessary for the splitting case which will produce unpredictable output files, the multiple entry-point case will produce multiple files but those files will have predictable names based on the esbuild configuration.

Describe the feature

Setting entry_points will correctly declare outputs for each of the bundled outputs and source maps etc and only switch to output directory declaration if splitting is enabled.

What is the current behavior?

Developers need to minify for production, but minified code during development is just a nuisance. This is a common pattern in compilers which can produce "stripped" or "optimized" vs. "debug" binaries.

Currently the minify flag has to be a boolean in the BUILD file, so developers have to manually change it, or use a select to make it configurable based on some command-line flag.

Describe the feature

We should probably just honor the --compilation_mode flag, as many Bazel users have --compilation_mode=opt in their release configuration. For backwards compat, we could have trinary similar to stamping behavior:

• minify = True is always minify
• minify = False is never minify
• minify = None is "honor the --compilation_mode"

What happened?

Libraries such as lodash-es relies on "sideEffects": false field in their package.json to property eliminate (tree-shake) unused utilities in the resulting bundle. But rules_esbuild does not seem to respect this field, resulting in large bundles when lodash-es is a dependency.

Disabling Bazel sandbox plugin does not resolve the issue (although there is a very noticeable performance difference).

See "How to reproduce" section for a minimal repro.

Version

Development (host) and target OS/architectures:

Output of bazel --version: aspect 5.8.19

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file: rules_esbuild 0.18.0, rules_js 1.37.0

Language(s) and/or frameworks involved:

How to reproduce

Repro: https://github.com/pyrocat101/esbuild_side_effects_repro

# Produces a large bundle file, where every operator in lodash-es is included in the resulting bundle.
bazel build //:bundle
# Produces a small bundle where only the implementation of used utility is included.
pnpm install
npx esbuild --bundle --format=esm --target=node18 index.js

Any other information?

No response

I know this is a super old version, but it's the last version that had support to downtranspile certain features to ES5 like const or destructuring. This will not be needed if evanw/esbuild#297 is closed

What happened?

I have an esbuild rule that I would assume is bundling a small config and it should have dependencies built into the output. However, on CI we found that the bundled config was missing the node_modules that were passed into the deps array for the esbuild rule call. See example code below

esbuild(
    name = "_syncpack.config.min",
    entry_point = "syncpack.config.js",
    # This file must always be CJS for syncpack to not ignore it
    # If it is not CJS, syncpack will silently fail and default
    # to it's own config, which will cascade into a failure on
    # our end since it will fail to exit 1 on CI
    format = "cjs",
    minify = True,
    # setting node as the platform will default us to CJS
    platform = "node",
    target = "esnext",
    deps = [
        "//arcanist/linters/linters/syncpack:node_modules",
    ],
)

bin.syncpack_lint_semver_ranges_binary(
    name = "lint-semver-ranges",
    args = [
        "--config",
        "$(execpath :_syncpack.config.min.js)",
    ],
    # this sets the tool to run from the root of the monorepo source tree
    chdir = "$$BUILD_WORKSPACE_DIRECTORY",
    data = [
        ":_syncpack.config.min.js",
    ],
)

This manifested in the config silently failing due to missing dependencies which I fixed by passing node_modules to the data array in the js_binary.

Note, the js_binary target is executed via bazel run

Version

Development (host) and target OS/architectures:

Output of bazel --version: 6.1.0

Version of the Aspect rules, or other relevant rules from your
WORKSPACE or MODULE.bazel file:

Language(s) and/or frameworks involved:

How to reproduce

Bazel run a target that takes a config built with esbuild as input and pass it to the runner. In this case, it's syncpack. Feel free to also reach out to me for more info.

Any other information?

No response

What happened?

(23:01:44) ERROR: An error occurred during the fetch of repository 'aspect_rules_esbuildoverrideesbuild~esbuild_windows-x64':

  | Traceback (most recent call last):
  | File "C:/b/nvszoz5g/external/aspect_rules_esbuild~override/esbuild/repositories.bzl", line 24, column 24, in _esbuild_repo_impl
  | integrity = esbuild[repository_ctx.attr.platform]
  | Error: key "windows-x64" not found in dictionary

Version

0.14.0

How to reproduce

https://buildkite.com/bazel/bcr-presubmit/builds/942#0185e0c6-425b-4dba-8e22-d7bf64593a3e

Any other information?

No response

Fund our work

• Sponsor our open source work by donating a bug bounty

What happened?

Per preceding discussion in the "javascript" channel of the "Bazel" Slack workspace, when using the latest version of rules_esbuild with the esbuild rule's new "bazel_sandbox_plugin" attribute (per #160) set to its default value of True, I find that TypeScript files that import other files from the same directory get rejected by the "bazel-sandbox" plugin. These files are referencing the adjacent files like this:

import classes from './Something.module.scss';

If I replace that with a bare file name, it seems to work without complaint:

import classes from 'Something.module.scss';

Is that intended behavior for this plugin? I see that it looks for paths that start with a period as one of its special cases that require it to carry on with remapping the resolved path under the execution root path.

It's possible for me to rewrite these paths in the import statements without the leading ./ as I showed above, but, unfortunately, when I do so, our linter programs can't process these files correctly. The only way I've found so far to allow our esbuild targets to continue building as they had been is to disable this plugin, setting the "bazel_sandbox_plugin" attribute to False.

Version

Development (host) and target OS/architectures: macOS, ARM64

Output of bazel --version: bazel 7.0.2

Version of the Aspect rules, or other relevant rules from your
WORKSPACE.bazel or MODULE.bazel file:

• aspect_bazel_lib: 2.4.1
• aspect_rules_esbuild: 0.18.0
• aspect_rules_js: 1.37.1
• aspect_rules_ts: 2.1.1
• aspect_rules_webpack: 0.14.0

Language(s) and/or frameworks involved: JavaScript, TypeScript

How to reproduce

No response

Any other information?

No response

Initial POC: f171ae0

Notes:

• using the js API today allows use of esbuild plugins written in js and passed via esbuild(config)
• using the the js or go API only allows plugins in that language, using the raw binary means no plugins?

What happened?

When using the esbuild module to build something that contains plugins, the sandbox plugin ends up in an infinite recursion. It keeps going until it eventually runs out of memory.

Version

osx, bazel 7.2.0rc1, rules_esbuild from git

How to reproduce

The bug was introduced by #160 / e39ac34

I am able to reproduce it with this minimal esbuild config:

const stylePlugin = require('esbuild-style-plugin');

module.exports = {
  plugins: [
    stylePlugin({}),
  ],
}

Any other information?

This happens because the sandbox sets otherOptions.pluginData.executedSandboxPlugin and expects it to be passed back, however if esbuild has other plugins defined it is not guaranteed that the other plugin will pass it otherOptions again (as this is not required by the esbuild plugin specification).

I've tried to fix it but without much luck (I'm not a js dev). Disabling the sandbox solves the problem but it's obviously not ideal 😄

I have two bazel repositories, and I'd like for one to depend on the other. One defines an esbuild macro. (I tried with an esbuild_bundle rule as well), The second imports the first as a local repository:

In the second WORKSPACE, I have:

local_repository(
    name = "bridge-deal",
    path = "/home/kyle/devel/bridge-deal"
)

If I execute bazelisk build "@bridge-deal//:bundle I get the following error:

ERROR: /home/kyle/.cache/bazel/_bazel_kyle/81db66b89528850bd748567d4113aa93/external/bridge-deal/BUILD.bazel:4:15: Bundling Javascript ../bridge-deal/app.ts [esbuild] failed: (Exit 1): launcher.sh failed: error executing command bazel-out/k8-opt-exec-2B5CBBC6/bin/external/esbuild_linux-64/launcher.sh '--esbuild_args=../bridge-deal/bundle.args.json'

I've attached a minimal reproduction. In minimal-repro-js, bazelisk build //:bundle works. in minimal-repro, bazelisk build @minimal-repro-js//:bundle fails with an error similar to the one I posted above.
minimal-repro.tar.gz

Hopefully this gives you a hint as to where the problem is.

Hey,

I couldn't decide if this is an issue with the esbuild rules, npm_link_all_packages, or how I'm working, so please let me know if I've got this wrong.

If I have a BUILD.bazel file in the root like this:

load("@aspect_rules_esbuild//esbuild:defs.bzl", "esbuild")
load("@npm//:defs.bzl", "npm_link_all_packages")

npm_link_all_packages(name = "node_modules")

esbuild(
    name = "index",
    entry_point = "index.ts",
    deps = [
        ":node_modules/http-errors",
    ],
)

Here index.ts is just importing http-errors as you'd typically expect, http-errors is listed in the package.json, and everything has been installed through pnpm.

When I try and build, however, esbuild is unable to find the dependencies of http-errors: depd, setprototypeof, statuses, inherits, and toidentifier, and fails:

✘ [ERROR] Could not resolve "depd"

    node_modules/http-errors/index.js:15:24:
      15 │ var deprecate = require('depd')('http-errors')
         ╵                         ~~~~~~

If I were to add the dependencies to the deps attribute, :node_modules/depd, I get another error because npm_link_all_packages only linked http-errors and not its dependencies.

Not sure what the right thing is here. One option would be to add all transitive dependencies to the package.json file, but that creates a lot of overhead during dependency upgrades if versions get out of line. I guess another option is to mark them all as external, but there again that would create a lot of overhead to track deps of deps.

Is there a recommended way to do this?

What happened?

I am upgrading aspect_rules_esbuild from version v0.16.0 to v0.18.0. Everything is working in v16 however in v18 I am getting the following errors from esbuild. (I couldn't check v0.17.0 because its not in the bazel registry)

✘ [ERROR] Could not read from file: /.../bin/node_modules/.aspect_rules_js/[email protected]/node_modules/object-inspect/util.inspect

    node_modules/.aspect_rules_js/[email protected]/node_modules/object-inspect/index.js:68:26:
      68 │ var utilInspect = require('./util.inspect');`

This happens because the object-inspect main file is requiring the file that is marked as non-browser.

This dependency is sadly commonly used in multiple packages such as react-dev-utils, cypress or webpack

Version

Development (host) and target OS/architectures:
Linux 5.15.146.1-microsoft-standard-WSL2 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Output of bazel --version:
bazel 7.0.2

Version of the Aspect rules, or other relevant rules from your MODULE.bazel file:

• aspect_rules_esbuild @ 0.18.0
• aspect_rules_js @ 1.38.0

Language(s) and/or frameworks involved:
pnpm

How to reproduce

No response

Any other information?

No response

When trying to use this ruleset with current (aspect-build/rules_js@61b1867) rules_js, I receive the following error:

ERROR: Traceback (most recent call last):
	File "/Users/john/figma/figma/WORKSPACE.bazel", line 120, column 28, in <toplevel>
		esbuild_register_toolchains(
	File "/private/var/tmp/_bazel_johnfirebaugh/67beefda950d56283b98d96980e6e332/external/aspect_rules_esbuild/esbuild/repositories.bzl", line 100, column 15, in esbuild_register_toolchains
		npm_import(
	File "/private/var/tmp/_bazel_johnfirebaugh/67beefda950d56283b98d96980e6e332/external/aspect_rules_js/js/npm_import.bzl", line 32, column 5, in npm_import
		def npm_import(
Error: npm_import() got unexpected keyword argument: enable_lifecycle_hooks

What is the current behavior?

Currently rules_esbuild only runs esbuild with bundle=true.

Describe the feature

Support bundle=false and properly propagate transitive dependencies and sources in this case.

Fund our work

• Sponsor our open source work by donating a feature bounty

Throughout the code base of rules_esbuild there are multiple places which make it impractical if not impossible to use a typescript entry point and have esbuild resolve depedencies using a tsconfig.json file.

To start this is this line which explictly removes the ability to pass esbuild a tsconfig file:

Secondly, when gathering transitive input sources, only files from js_providers are considered and the rest are thrown out: https://github.com/aspect-build/rules_esbuild/blob/main/esbuild/private/esbuild.bzl#L301

This is problematic since it leaves no way for targets to specify runtime dependencies they want to make available to esbuild during bundling. A common use case for this is to have a css import in a .ts or .js file import ./index.css. One would make index.css a data dependency of their ts_project or js_library target, expecting that this would make it so that the esbuild bundler would make the file available during bundling. However, this is not the case.

The only way to include non .js files is to specify the entire transitive closure of targets you need available within the srcs attribute. This is not sufficient for builds with many transitive dependencies. Each transitive dep should be able to declare what it needs to have available during bundling.

What is the current behavior?

A platform-specific binary release of esbuild is downloaded and used for the esbuild binary. There are notes on how to configure a custom toolchain binary but no quick and easy code snippet.

I am able to get a custom version of esbuild working, but only with modifications of the rules_esbuild source (see #120 and in particular the change to esbuild.bzl, which seems necessary to properly set the ESBUILD_BINARY_PATH environment variable).

Describe the feature

Add a snippet that can be copy-pasted to easily use the version built from go source.

#120 allows an alternative binary to be specified like so:

esbuild_register_toolchains(
    name = "esbuild",
    esbuild_version = "0.17.5",
    target_tool = "@com_github_evanw_esbuild//cmd/esbuild",
)

Merging that PR (or something like it) is a possibility, I suppose.

Fund our work

• Sponsor our open source work by donating a feature bounty

Such as when source is copied into a directory using copy_to_directory.

Should it support https://github.com/aspect-build/bazel-lib/blob/main/docs/directory_path.md or similar?

Example: https://github.com/jbedard/rules_esbuild/tree/multi-dirs/examples/gen_entries

It seems like esbuild isn't consuming linked npm modules. The directory structure seems to be correctly layed out but esbuild fails.

Example: https://github.com/jbedard/rules_esbuild/tree/npm-link-package/e2e/npm-links

Currently the macro is esbuild and the underlying rule is esbuild_bundle. This is be aligned like our other rules sets since this is not a great pattern.

Hey!

With the following BUILD.bazel file contents:

load("@aspect_rules_esbuild//esbuild:defs.bzl", "esbuild")

esbuild(
    name = "bundle",
    entry_point = "index.ts",
    splitting = True,
)

I expected a bundle subdir in bazel-bin with the generated JS. The metadata, args, and config files are created, but the bundle subdir remains empty with no generated JS in it. Am I missing a particular attribute?

Originally reported in #32 (comment):

Another problem with preserveSymlinks = false for our needs in Bazel is that ESBuild leaves comments in the output that contain resolved file paths. With preserveSymlinks = false these can refer to paths like .../home/matt/.cache/bazel_matt/.../.../... which, across different users and checkouts, will generate downstream cache misses on actions that depend on the outputs.

At Figma we encountered this issue with a write_source_files target that writes an esbuild bundle. The associated diff_test fails with rules_esbuild 0.12+ because the generated relative path differs between local development and CI.

What is the current behavior?

If I define assetNames in config, a new folder will be created in Bazel output, but the folder is not included in the rule's output. It means it is impossible to manage it or use it with output_dir=False.

Describe the feature

It would be great to add support for assetNames to specify the assets output folder (needed for GitLab Pages website deployment under the custom path).

In theory, we can add something like output_assets=Label() in order to get assets from esbuild

Fund our work

• Sponsor our open source work by donating a feature bounty

What is the current behavior?

Currently we can only pass a single target string to the rule.

Describe the feature

The cli supports passing multiple targets and will bundle based on the minimum support needed.

See the example here: https://esbuild.github.io/api/#target

I think it should be a simple fix to support passing an array of target strings rather than a single string via the rule.

With @bazel/esbuild I was using args to supply a globalName argument. It doesn't look like there's a way to do this in rules_esbuild, either via a generic args parameter or one specific to globalName.

Yeah I was going to comment that we should include that macro here
https://github.com/bazelbuild/rules_nodejs/blob/stable/packages/esbuild/test/plugins/BUILD.bazel#L21-L37

Currently there's no way to pass args directly to the ESBuild executable. I'd like to use the "log-override" arg (https://esbuild.github.io/api/#log-override), but I don't think there's any way to use this currently. Am I correct?

I think the way to do this would be to allow the user to pass through args into launcher_args:
https://github.com/aspect-build/rules_esbuild/blob/main/esbuild/private/esbuild.bzl#L265