aspect-build / rules_esbuild Goto Github PK
View Code? Open in Web Editor NEWBazel rules for https://esbuild.github.io/ JS bundler
Home Page: https://docs.aspect.build/rules/aspect_rules_esbuild
License: Apache License 2.0
Bazel rules for https://esbuild.github.io/ JS bundler
Home Page: https://docs.aspect.build/rules/aspect_rules_esbuild
License: Apache License 2.0
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
.
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
Initial POC: f171ae0
Notes:
esbuild(config)
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.
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.
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
It seems that if output_dir
is true, a directory artifact is declared using the rule name as the folder name.
rules_esbuild/esbuild/private/esbuild.bzl
Lines 255 to 257 in cede902
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?
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?
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)).
Options for the esbuild rule only allow for truthy source map options, there is no way to disable source maps.
Code in question:
rules_esbuild/esbuild/private/esbuild.bzl
Line 204 in 65d93ac
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:
No response
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
Currently rules_esbuild
only runs esbuild
with bundle=true
.
Support bundle=false
and properly propagate transitive dependencies and sources in this case.
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
}
)
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]
No response
No response
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:
format
is going to be ignored in the case above, is it possible to emit a warning or notice?format
independently of platform
, target
, and whether you're using entry_point
or entry_points
. Is that possible here?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
See above :)
No response
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
.
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).
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.
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
| 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
0.14.0
https://buildkite.com/bazel/bcr-presubmit/builds/942#0185e0c6-425b-4dba-8e22-d7bf64593a3e
No response
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.
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
.bazelversion
bazel 5.3.1
.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
e2e/npm-links/package.json
numeral ^2.0.6
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.
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.
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.
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:
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
No response
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
.
The default node toolchain is used.
Specify a custom node toolchain similar to js_binary and similar rules.
Currently we can only pass a single target
string to the rule.
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.
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
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:
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.
No response
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.
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 minifyminify = False
is never minifyminify = None
is "honor the --compilation_mode"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. WithpreserveSymlinks = 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.
No response
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?
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
.
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:
Language(s) and/or frameworks involved: JavaScript, TypeScript
No response
No response
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?
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
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
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:
Language(s) and/or frameworks involved:
pnpm
No response
No response
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:
rules_esbuild/esbuild/private/launcher.js
Line 60 in f3def54
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.
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'
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:
Just try to build anything which depends on the esbuild toolchain to trigger the error
No response
#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.
0.18.0
No response
No response
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
N/A
No response
No response
Not sure how to use --loader
option, e.g. --loader:.svg=text
Allow users to set --loader:.svg=text
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.
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
I have this repository to reproduce https://github.com/Exegetech/buggyesbuildproject
No response
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.