Giter Club home page Giter Club logo

rules_esbuild's People

Contributors

aghassi avatar alexeagle avatar arobinson avatar bduffany avatar brendean avatar dpoluyanov avatar github-actions[bot] avatar gregmagolan avatar jbedard avatar jdcole avatar jessetatasciore avatar jialipassion avatar josephglanville avatar koulmomo avatar longlho avatar mattem avatar pattrickrice avatar ralimi avatar realtimetodie avatar renovate[bot] avatar satajo avatar vpanta avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

rules_esbuild's Issues

[FR]: Add support for assetName esbuild API

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

esbuild fails when depending on a bundle in a local repository

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.

Align macro name & rule name

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.

[FR]: Should `output_dir` use `output` as the dir name rather than `name?

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.

if ctx.attr.output_dir:
js_out = ctx.actions.declare_directory("%s" % ctx.attr.name)
output_sources.append(js_out)

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?

esbuild fails with transitive dependencies

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?

esbuild leaves the sandbox

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)).

[Bug]: No ability to disable source maps

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:

if len(ctx.attr.sourcemap) > 0:

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

[FR]: Support for bundle=false

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

[Bug]: Can't set log level

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

[Bug/FR]: format is ignored unless splitting is set to True

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

Bundle needs both direct and transitive dependencies

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 .

[FR]: Example usage that builds esbuild from go_binary rule and possible bug with ESBUILD_BINARY_PATH

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

Mirror esbuild 0.11.20

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

[Bug]: bcr presubmit is red on windows

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

Dependency Dashboard

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.

Ignored or Blocked

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

Detected dependencies

bazel
esbuild/dependencies.bzl
  • bazel_skylib 1.3.0
  • aspect_bazel_lib v1.12.1
  • aspect_rules_js v1.4.0
  • rules_nodejs 5.5.4
internal_deps.bzl
  • io_bazel_rules_go v0.35.0
  • bazel_gazelle v0.26.0
  • bazel_skylib 1.1.1
  • io_bazel_stardoc 0.5.2
bazelisk
.bazelversion
  • bazel 5.3.1
github-actions
.github/workflows/ci.yaml
  • actions/checkout v3
  • actions/cache v3
.github/workflows/release.yml
  • actions/checkout v3
  • actions/cache v3
  • softprops/action-gh-release v1
npm
e2e/npm-links/package.json
  • numeral ^2.0.6

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

[FR]: Support entry_points with output_dir = False

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.

[Bug]: rules_esbuild does not tree-shake using `sideEffects` in `package.json`

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

[FR]: support multiple targets, in line with cli api

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.

[Bug]: rules_esbuild does not properly pass `deps` to js_binary

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

[FR]: control `minify` behavior with a flag

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"

esbuild output with `preserveSymlinks = false` contains machine-specific relative paths

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.

[FR]: Support bzlmod

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

[Bug]: bazel_sandbox_plugin rejects some relative import paths

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 remap 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

Code Splitting generates empty dir

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?

[Bug]: Upgrading from v0.16.0 to v0.18.0 causes non-browser scripts to throw an error

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

esbuild rule is incompatible with bundling from .ts sources

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.

[Bug]: rules_esbuild_dependencies fails with 0.14.0

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

[Bug]: bazel_sandbox_plugin is very slow

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

[FR]: --loader option

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

[Bug]: Esbuild doesn't correctly track dependencies

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

Incompatible with current rules_js

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.