feat: add BAZEL env variable to js_binary

[gregmagolan]

Differentiating between Bazel and non-Bazel environments is very common and to date users have been using either BAZEL_TEST or JS_BINARY__* env vars. The former is not set by bazel under bazel run and the latter is not particularly ergonomic. BAZEL is simpler and easier to remember.

---

Type of change

• New feature or functionality (change which adds functionality)

Test plan

• New test cases added

[alexeagle]

Did you search for a conventional variable set in other languages? What do ppl do there?

[gregmagolan]

Did you search for a conventional variable set in other languages? What do ppl do there?

If you take the CI vendors & tools as an example, they all set CI and each vendor/tool also sets their own specific env var such as BUILDKITE, CIRCLECI, GITLAB_CI, GITHUB_ACTIONS, TRAVIS, APPVEYOR.

https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables

GITHUB_ACTIONS | Always set to true when GitHub Actions is running the workflow. You can use this variable to differentiate when tests are being run locally or by GitHub Actions.

https://buildkite.com/docs/pipelines/environment-variables#buildkite-environment-variables

BUILDKITE #This value cannot be modified | Always true

https://circleci.com/docs/variables/#built-in-environment-variables

CIRCLECI | GitHub OAuth, GitHub App, Bitbucket, GitLab | Boolean | true (represents whether the current environment is a CircleCI environment)

Setting BAZEL seems analogous to these so that programs can detect their environment from a simple well-known env var. I think Bazel should handle this in the core since bazel run a tool is a common enough use can in all ecosystems.

[gregmagolan]

I haven't seen the bazel run case handled in other ecosystems. Cases I've seen, users are keying off of BAZEL_TEST for test targets or setting explicit envs such as BAZEL on the target to detect if under Bazel for bazel run.

[jbedard]

Bazel itself sets BAZEL_TEST though, not rules_js? Should we avoid setting anything without a JS pre/suffix? How about RULES_JS or JS_TEST|RUN|BUILD etc?

[gregmagolan]

Bazel itself sets BAZEL_TEST though, not rules_js? Should we avoid setting anything without a JS pre/suffix? How about RULES_JS or JS_TEST|RUN|BUILD etc?

Yes, tho BAZEL_TEST is only set when you run bazel test so there is a gap for users that run programs with bazel run to be able to detect in an easy and ergonomic way they are underly Bazel. An env var such as JS_RUN doesn't read well in end-user code since it isn't obvious that you're checking for bazel that way.

There is precedent for setting BAZEL_* var in rules_js already in js_run_binary:

    fixed_env = {
        "BAZEL_BINDIR": "$(BINDIR)",
        "BAZEL_BUILD_FILE_PATH": "$(BUILD_FILE_PATH)",
        "BAZEL_COMPILATION_MODE": "$(COMPILATION_MODE)",
        "BAZEL_PACKAGE": native.package_name(),
        "BAZEL_TARGET_CPU": "$(TARGET_CPU)",
        "BAZEL_TARGET_NAME": name,
        "BAZEL_TARGET": "$(TARGET)",
        "BAZEL_WORKSPACE": "$(WORKSPACE)",
    }

[alexeagle]

I'm just nitpicking this because every added variable has the potential to collide with something the user already set, and shorter is more likely.

[gregmagolan]

I'm just nitpicking this because every added variable has the potential to collide with something the user already set, and shorter is more likely.

I do check if it is already set and don't set override it if it is. Perhaps I should create an issue on bazelbuild/bazel so that bazel itself sets BAZEL to 1 in all cases including bazel run?

[alexeagle]

A bit related: bazelbuild/bazel#15470