flatbuffers/ts/BUILD.bazel

58 lines
1.5 KiB
Python
Raw Normal View History

load("@npm//@bazel/typescript:index.bzl", "ts_project")
load("@build_bazel_rules_nodejs//:index.bzl", "js_library")
ts_project(
name = "flatbuffers_ts",
srcs = [
"builder.ts",
"byte-buffer.ts",
"constants.ts",
"encoding.ts",
[TS/JS] Entry point per namespace and reworked 1.x compatible single file build (#7510) * [TS/JS] Entry point per namespace * Fix handling of outputpath and array_test * Attempt to fix generate_code * Fix cwd for ts in generate_code * Attempt to fixup bazel and some docs * Add --ts-flat-files to bazel build to get bundle * Move to DEFAULT_FLATC_TS_ARGS * Attempt to add esbuild * Attempt to use npm instead * Remove futile attempt to add esbuild * Attempt to as bazel esbuild * Shuffle * Upgrade bazel deps * Revert failed attempts to get bazel working * Ignore flatc tests for now * Add esbuild dependency * `package.json` Include esbuild * `WORKSPACE` Add fetching esbuild binary * Update WORKSPACE * Unfreeze Lockfile * Update WORKSPACE * Update BUILD.bazel * Rework to suggest instead of running external bundler * Add esbuild generation to test script * Prelim bundle test * Run test JavaScriptTest from flatbuffers 1.x * Deps upgrade * Clang format fix * Revert bazel changes * Fix newline * Generate with type declarations * Handle "empty" root namespace * Adjust tests for typescript_keywords.ts * Separate test procedure for old node resolution module output * Fix rel path for root level re-exports * Bazel support for esbuild-based flatc Unfortunately, we lose typing information because the new esbuild method of generating single files does not generate type information. The method used here is a bit hack-ish because it relies on parsing the console output of flatc to figure out what to do. * Try to fix bazel build for when node isn't present on host * Auto formatting fixes * Fix missing generated code Co-authored-by: Derek Bailey <derekbailey@google.com> Co-authored-by: James Kuszmaul <jabukuszmaul+collab@gmail.com>
2023-01-21 20:22:22 +00:00
"flatbuffers.ts",
"types.ts",
"utils.ts",
],
declaration = True,
tsconfig = {
"compilerOptions": {
"module": "commonjs",
"declaration": True,
"moduleResolution": "node",
"lib": [
"ES2015",
"ES2020.BigInt",
"DOM",
],
"types": ["node"],
"strict": True,
},
},
visibility = ["//visibility:public"],
deps = ["@npm//@types/node"],
)
js_library(
name = "flatbuffers",
package_name = "flatbuffers",
visibility = ["//visibility:public"],
deps = [":flatbuffers_ts"],
)
[TS/JS] Entry point per namespace and reworked 1.x compatible single file build (#7510) * [TS/JS] Entry point per namespace * Fix handling of outputpath and array_test * Attempt to fix generate_code * Fix cwd for ts in generate_code * Attempt to fixup bazel and some docs * Add --ts-flat-files to bazel build to get bundle * Move to DEFAULT_FLATC_TS_ARGS * Attempt to add esbuild * Attempt to use npm instead * Remove futile attempt to add esbuild * Attempt to as bazel esbuild * Shuffle * Upgrade bazel deps * Revert failed attempts to get bazel working * Ignore flatc tests for now * Add esbuild dependency * `package.json` Include esbuild * `WORKSPACE` Add fetching esbuild binary * Update WORKSPACE * Unfreeze Lockfile * Update WORKSPACE * Update BUILD.bazel * Rework to suggest instead of running external bundler * Add esbuild generation to test script * Prelim bundle test * Run test JavaScriptTest from flatbuffers 1.x * Deps upgrade * Clang format fix * Revert bazel changes * Fix newline * Generate with type declarations * Handle "empty" root namespace * Adjust tests for typescript_keywords.ts * Separate test procedure for old node resolution module output * Fix rel path for root level re-exports * Bazel support for esbuild-based flatc Unfortunately, we lose typing information because the new esbuild method of generating single files does not generate type information. The method used here is a bit hack-ish because it relies on parsing the console output of flatc to figure out what to do. * Try to fix bazel build for when node isn't present on host * Auto formatting fixes * Fix missing generated code Co-authored-by: Derek Bailey <derekbailey@google.com> Co-authored-by: James Kuszmaul <jabukuszmaul+collab@gmail.com>
2023-01-21 20:22:22 +00:00
sh_binary(
name = "compile_flat_file",
srcs = ["compile_flat_file.sh"],
data = [
"@com_github_google_flatbuffers//:flatc",
"@nodejs_linux_amd64//:node_bin",
"@npm//esbuild/bin:esbuild",
[TS/JS] Entry point per namespace and reworked 1.x compatible single file build (#7510) * [TS/JS] Entry point per namespace * Fix handling of outputpath and array_test * Attempt to fix generate_code * Fix cwd for ts in generate_code * Attempt to fixup bazel and some docs * Add --ts-flat-files to bazel build to get bundle * Move to DEFAULT_FLATC_TS_ARGS * Attempt to add esbuild * Attempt to use npm instead * Remove futile attempt to add esbuild * Attempt to as bazel esbuild * Shuffle * Upgrade bazel deps * Revert failed attempts to get bazel working * Ignore flatc tests for now * Add esbuild dependency * `package.json` Include esbuild * `WORKSPACE` Add fetching esbuild binary * Update WORKSPACE * Unfreeze Lockfile * Update WORKSPACE * Update BUILD.bazel * Rework to suggest instead of running external bundler * Add esbuild generation to test script * Prelim bundle test * Run test JavaScriptTest from flatbuffers 1.x * Deps upgrade * Clang format fix * Revert bazel changes * Fix newline * Generate with type declarations * Handle "empty" root namespace * Adjust tests for typescript_keywords.ts * Separate test procedure for old node resolution module output * Fix rel path for root level re-exports * Bazel support for esbuild-based flatc Unfortunately, we lose typing information because the new esbuild method of generating single files does not generate type information. The method used here is a bit hack-ish because it relies on parsing the console output of flatc to figure out what to do. * Try to fix bazel build for when node isn't present on host * Auto formatting fixes * Fix missing generated code Co-authored-by: Derek Bailey <derekbailey@google.com> Co-authored-by: James Kuszmaul <jabukuszmaul+collab@gmail.com>
2023-01-21 20:22:22 +00:00
],
# We just depend directly on the linux amd64 nodejs binary, so only support
# running this script on amd64 for now.
target_compatible_with = [
"@platforms//cpu:x86_64",
"@platforms//os:linux",
],
visibility = ["//visibility:public"],
deps = ["@bazel_tools//tools/bash/runfiles"],
)