angular/tools/bazel/node_loader/BUILD.bazel

load("@aspect_rules_js//js:defs.bzl", "js_library")

js_library(
    name = "node_loader_lib",
    srcs = glob(
        ["*.mjs"],
        exclude = ["index.mjs"],
    ),
    visibility = ["//visibility:public"],
    deps = ["//:node_modules/get-tsconfig"],
)

js_library(
    name = "node_loader",
    srcs = ["index.mjs"],
    visibility = ["//visibility:public"],
    deps = [":node_loader_lib"],
)
build: introduce NodeJS loader for `rules_js` Node execution (#61865) For the `rules_js` migration, we are facing the problem where our current Angular code is shipped as ESM, but we aren't fully there yet with fully compliant strict ESM during development. That is because we lack explicit import extensions, and it's also a different story how this would work in Google3, if we were to add them. In addition, we cross-import from our packages using npm module names. This works well for TS, for ESBuild because those can respect path mappings— but at runtime, when executing native `jasmine_test`'s— such mappings aren't respected. The options here are: - avoid module imports in the repo (impossible; undesired) - use pre-bundling of all NodeJS execution involving npm package code (slower, extra build action cost) - wire up a simple NodeJS loader (supported via official APIs) to simply account for our cases (preferred and similar to what we experimented with for the last year(s); and worked well) This commit implements the last option and allows for an easy migration to `rules_js`, and also is pretty reasonable. Long-term we can resolve the extension problem if we e.g. migrate to real explicit extensions + a proper TS module resolution like e.g. `nodenext`. PR Close #61865 2025-06-04 13:08:45 +00:00			`load("@aspect_rules_js//js:defs.bzl", "js_library")`

			`js_library(`
build: standardize usage of js_binary (#62860) Remove usages of nodejs_binary and use a commonly defined js_binary macro PR Close #62860 2025-07-28 20:15:17 +00:00			`name = "node_loader_lib",`
			`srcs = glob(`
			`["*.mjs"],`
			`exclude = ["index.mjs"],`
			`),`
build: introduce NodeJS loader for `rules_js` Node execution (#61865) For the `rules_js` migration, we are facing the problem where our current Angular code is shipped as ESM, but we aren't fully there yet with fully compliant strict ESM during development. That is because we lack explicit import extensions, and it's also a different story how this would work in Google3, if we were to add them. In addition, we cross-import from our packages using npm module names. This works well for TS, for ESBuild because those can respect path mappings— but at runtime, when executing native `jasmine_test`'s— such mappings aren't respected. The options here are: - avoid module imports in the repo (impossible; undesired) - use pre-bundling of all NodeJS execution involving npm package code (slower, extra build action cost) - wire up a simple NodeJS loader (supported via official APIs) to simply account for our cases (preferred and similar to what we experimented with for the last year(s); and worked well) This commit implements the last option and allows for an easy migration to `rules_js`, and also is pretty reasonable. Long-term we can resolve the extension problem if we e.g. migrate to real explicit extensions + a proper TS module resolution like e.g. `nodenext`. PR Close #61865 2025-06-04 13:08:45 +00:00			`visibility = ["//visibility:public"],`
			`deps = ["//:node_modules/get-tsconfig"],`
			`)`
build: standardize usage of js_binary (#62860) Remove usages of nodejs_binary and use a commonly defined js_binary macro PR Close #62860 2025-07-28 20:15:17 +00:00
			`js_library(`
			`name = "node_loader",`
			`srcs = ["index.mjs"],`
			`visibility = ["//visibility:public"],`
			`deps = [":node_loader_lib"],`
			`)`