fix(builtin): look in the execroot for nodejs_binary source entry_points (#1816) In a6e29c2add19dd487035b0951f5271053a0a11e2 we added support for generated entry_point by adding a secondary lookup. In 863c7de48046c35dfe29f6a4f625ca3e7057b030 we reversed the order of the lookups to make rollup work in a certain use case. Neither of these was principled, because we know ahead of time whether the entry_point is generated. We can use a single lookup. However that depends on running the linker on all generated bin rules, which is a breaking change, so for now we just defer the FS check until after the linker runs. This also makes sure that programs run in the location where the linker will put them (note that the logic in question runs before the linker has created the node_modules directory in the execroot.) This is why #1787 observes that some node programs were broken - we were running the entry point as bazel-out/host/bin/external/npm/@graphql-codegen/cli/bin/graphql-codegen.sh.runfiles/npm/node_modules/@graphql-codegen/cli/bin.js when it should have been node_modules/@graphql-codegen/cli/bin.js Fixes #1787
| Circle CI | Bazel CI |
|---|---|
 |  |
The nodejs rules integrate NodeJS development toolchain and runtime with Bazel.
This toolchain can be used to build applications that target a browser runtime, so this repo can be thought of as “JavaScript rules for Bazel” as well. (We would call this rules_javascript if renames weren't so disruptive.)
Comprehensive documentation for installing and using the rules, including generated API docs: https://bazelbuild.github.io/rules_nodejs/
This is the fastest way to get started. See the installation documentation for details and alternative methods, or if you already have a Bazel project and you're adding Node/JavaScript support to it.
$ npm init @bazel
or if you prefer yarn,
$ yarn create @bazel
These commands are equivalent to
npx @bazel/createwhich downloads the latest version of the@bazel/createpackage from npm and runs the program contained.
See the output of the tool for command-line options and next steps.
Thanks to the following active users!
Open-source repositories:
Organizations:
Not on this list? Send a PR to add your repo or organization!
From Lewis Hemens at Dataform:
At Dataform we manage a number of NPM packages, Webpack builds, Node services and Java pipelines across two separate repositories. This quickly became hard for us to manage, development was painful and and deploying code required a many manual steps. We decided to dive in and migrate our build system entirely to Bazel. This was a gradual transition that one engineer did over the course of about 2 months, during which we had both Bazel and non bazel build processes in place. Once we had fully migrated, we saw many benefits to all parts of our development workflow:
- Faster CI: we enabled the remote build caching which has reduced our average build time from 30 minutes to 5 (for the entire repository)
- Improvements to local development: no more random bash scripts that you forget to run, incremental builds reduced to seconds from minutes
- Simplified deployment processes: we can deploy our code to environments in Kubernetes with just one command that builds and pushes images
- A monorepo that scales: adding new libraries or packages to our repo became easy, which means we do it more and end up write more modular, shared, maintainable code
- Developing across machine types: our engineers have both Macbooks and Linux machines, bazel makes it easy to build code across both
- Developer setup time: New engineers can build all our code with just 3 dependencies - bazel, docker and the JVM. The last engineer to join our team managed to build all our code in < 30 minutes on a brand new, empty laptop