[bazel] Integrate packages

[tylersmalley]

In this phase, we set out to provide the necessary infrastructure outlined previously to begin utilizing Bazel and begin doing so by migrating the current 38 packages.

A BUILD.bazel file will be added to the root of each package defining a build target. This filegroup target will be what we call during the bootstrap phase to build all packages migrated to Bazel. This target is temporary to maintain similar functionality during our transition. In the future, these procedural build steps will be removed in favor of dependency, tree-driven actions where work will only be done if it’s necessary for the given task like running the Kibana server or executing a unit test.

The @kbn/pm package will be updated to allow for the existing legacy builds to run in parallel with the new packages build target, invoked by calling bazel build //packages:build.

The build targets will no longer reside within the package themselves and instead will be within the bazel/bin directory. To account for this, any defined dependency on this will need to be updated to reference the new directory (example: link:bazel/bin/packages/elastic-datemath). While also in this transition period, the build will need to copy over the packages from bazel/bin into the node_modules of the build target.

Example package BUILD.bazel for packages/elastic-datemath:

load("@build_bazel_rules_nodejs//:index.bzl", "pkg_npm")
load("@build_bazel_rules_nodejs//internal/js_library:js_library.bzl", "js_library")

SRCS = [
    ".npmignore",
    "index.js",
    "index.d.ts",
    "package.json",
    "readme",
    "tsconfig.json",
]

filegroup(
    name = "src",
    srcs = glob(SRCS),
)

js_library(
    name = "elastic-datemath",
    srcs = [ ":src" ],
    deps = [ "@npm//moment" ],
    package_name = "@elastic/datemath",
    visibility = ["//visibility:public"],
)

alias(
    name = "build",
    actual = "elastic-datemath",
    visibility = ["//visibility:public"],
)

If the package has unit tests, they will need to also be migrated to be invoked with bazel test as described in the Unit Testing section.

Within Bazel, the packages will have new overall rules:

• It cannot contain build scripts. Every package build will be written using a Bazel BUILD.bazel file
• It cannot have side effects. Every package build should be cacheable and reproducible and should not produce any side effects
• Each package should define three major public target rules on Bazel BUILD.bazel files: build, jest, and a js_library target with the same name of the folder where the package is living.
• Each package should have a set of npm scripts. The required ones are: build, watch. The optional ones are: test. The build script should just invoke “bazel build //packages/package_name:build”; The watch should call build with ibazel and pass the arguments “-- -node_options=--inspect-brk” like “ibazel build //packages/package_name:build -- -node_options=--inspect-brk” (need to test this) and finally for packages that define jest tests we should define a script that will call the unit tests target rule like bazel test //packages/package_name:jest
• In order to output its targets in the most Bazel friendly way, each package will output its target according to the following folder structure: for node targets, it will be target_server, for web target it will be target_web and for types, it will be target_types.

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[tylersmalley]

This has been completed.