fix: don't bake COMPILATION_MODE into launcher as exported environment var

This approach is incorrect as tools that are build for host such as "rollup_bin" in the rollup_bundle rule will see the --host_compilation_mode and not the --compilation_mode configuration value when built by Bazel as their cfg in the rule is correctly set to "host".

```
    "rollup_bin": attr.label(
        doc = "Target that executes the rollup binary",
        executable = True,
        cfg = "host",
        default = "@npm//rollup/bin:rollup",
    ),
```

The correct approach is to pass COMPILATION_MODE via the actions.run env attribute.

For the rollup_bundle rollup_bin tool, this is passed via run_node:

```
def run_node(ctx, inputs, arguments, executable, **kwargs):
    """Helper to replace ctx.actions.run
    This calls node programs with a node_modules directory in place"""
    ....
    # Forward the COMPILATION_MODE to node process as an environment variable
    env = kwargs.pop("env", {})
    if "COMPILATION_MODE" not in env.keys():
        env["COMPILATION_MODE"] = ctx.var["COMPILATION_MODE"]

    ctx.actions.run(
        inputs = inputs + extra_inputs,
        arguments = arguments,
        executable = exec_exec,
        env = env,
        **kwargs
    )
```

for other tools such the terser_minified terser_bin tool, this is done directly in ctx.actions.run:

```
    ctx.actions.run(
        inputs = inputs,
        outputs = outputs,
        executable = ctx.executable.terser_bin,
        arguments = [args],
        env = {"COMPILATION_MODE": ctx.var["COMPILATION_MODE"]},
        progress_message = "Minifying JavaScript %s [terser]" % (outputs[0].short_path),
    )
```

Accordingly `COMPILATION_MODE` is removed from default_env_vars so it is not baked into the launcher.sh.

`DEBUG` is also removed as a DEBUG define should not be default be passed to all nodejs_binary targets as it may unexpectantly affect the build outputs and if you do want to pass --define=DEBUG=1 to a tool such as the bazel_integration_test test_runner.js, also forwarding it to all nodejs_binaries will result in a massive
cache invalidation.
13 files changed
tree: e9c01090cabeb52731dacdb821eb8be47a7d3b32
  1. .bazelci/
  2. .circleci/
  3. .github/
  4. .vscode/
  5. docs/
  6. e2e/
  7. examples/
  8. internal/
  9. packages/
  10. scripts/
  11. third_party/
  12. toolchains/
  13. tools/
  14. .bazelignore
  15. .bazelrc
  16. .clang-format
  17. .gitignore
  18. .npmrc
  19. AUTHORS
  20. bootstrap.js
  21. BUILD.bazel
  22. CHANGELOG.md
  23. CODE_OF_CONDUCT.md
  24. commitlint.config.js
  25. common.bazelrc
  26. CONTRIBUTING.md
  27. CONTRIBUTORS
  28. defs.bzl
  29. DEVELOPING.md
  30. index.bzl
  31. index.for_docs.bzl
  32. LICENSE
  33. package.bzl
  34. package.json
  35. providers.bzl
  36. README.md
  37. renovate.json
  38. rules_typescript.patch
  39. stardoc.patch
  40. tsconfig.json
  41. WORKSPACE
  42. yarn.lock
README.md

JavaScript rules for Bazel

Circle CIBazel CI
CircleCIBuild status

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

Documentation

Comprehensive documentation for installing and using the rules, including generated API docs: https://bazelbuild.github.io/rules_nodejs/

Quickstart

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/create which downloads the latest version of the @bazel/create package from npm and runs the program contained.

See the output of the tool for command-line options and next steps.

Adopters

Thanks to the following active users!

Open-source repositories:

Organizations:

Not on this list? Send a PR to add your repo or organization!

User testimonials

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