bazelbuild/rules_typescript

MOVED to https://github.com/bazelbuild/rules_nodejs/tree/3.x/third_party/github.com/bazelbuild/rules_typescript

Moved to rules_nodejs monorepo: https://github.com/bazelbuild/rules_nodejs/tree/3.x/third_party/github.com/bazelbuild/rules_typescript

Readme content is preserved below to avoid breaking links

This repo contains a mirror of some Google-internal bits that support TypeScript development under Bazel.

It contains these utilities:

• ts_devserver: a Go library and binary that runs a fast local web server which concatenates JavaScript on-the-fly. It requires inputs in a named module format (module ids must be contained in the file, not inferred from the file's path).
• tsc_wrapped: a TypeScript program which wraps the TypeScript compiler, hosting it under a Bazel worker.
• tsetse: a collection of third-party "strictness" checks which we add to the TypeScript compiler.
• internal/common/*.bzl: some Starlark utility code for running the ts_library rule.

There are no user-facing bits in this repo. These utilities are consumed in https://github.com/bazelbuild/rules_nodejs/tree/master/packages/typescript

Please file issues for ts_library rule and other Bazel rules in that repo.

rules_typescript's Issues

non-hermetic reading of files is slow and non-cached

In particular, we don't cache the typescript lib.*.d.ts files, which are slow to parse and re-bind on each compilation.
Bazel should be able to tell us about all the input files, even the ones in node_modules, so it seems we should be able to prime the FileCache completely and remove the non-hermetic reading behavior.

Allow imports to be workspace-absolute

Internally at google we can write
import {thing} from 'google3/path/to/project'
because our workspace(name = "google3")

We should generalize this to other projects too.

npm repo is missing github link

Dear maintainers,

I am missing a link to the repository from the npm page (link). I assume that this repo right here is the one.

Can you please add an according reference?

Best regards,
Benedikt

Some projects cannot use yarn

eg. Angular uses npm with npm-shrinkwrap.json

Calling yarn from the bazel rules doesn't look at the shrinkwrap file, and may install different versions. This broke Angular's circleCI build because yarn installed TS 4.2. To make it worse, the node_modules directory is cached between builds, using the npm-shrinkwrap.json checksum as the key, so master stayed green even though PRs started failing when the new typescript was released.

Add a ts_devserver rule

This requires a few things:

• Each ts_library compilation should produce the _es5_manifest.MF file that lists the topo-sorted module graph observed in this compilation. We should decompose this out of tsickle where it currently lives, and put in a TS transformer. here's a pointer: https://github.com/angular/tsickle/blob/5ac90e8499acebbe828aa1314fcf4eb86dd6b08f/src/es5processor.ts#L113 - I am hoping @LucasSloan can help
  (note: we do this per-library to avoid re-parsing files when we get a request)
• we need to open-source the Go implementation of our devserver and concatjs programs. Maybe @mprobst would like to get this started?
• need the Bazel rule that runs the devserver
• test that it works with ibazel

/cc @vsavkin

Allow Typescript files/directories live in a subdirectory?

I have a project I'm building where I would like to place the Typescript files and Typescript configs (package.json and tsconfig.json) in a subdirectory of my workspace. AFAICT, this doesn't seem to be supported by these rules. Can you add docs or support for this? Thanks!

Warn the user when an option in tsconfig is ignored

In my tsconfig I have target: "es6". However, on bazel build src/shadowbox:model, bazel is outputting a model_es5_tsconfig.json file with contents:

{
  "compilerOptions": {
    "target": "es5",
    "downlevelIteration": true,
    "skipDefaultLibCheck": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "outDir": "../../../../../../bazel-out/local-fastbuild/bin",
    "rootDir": "../../../../../..",
    "rootDirs": [
      "../../../../../..",
      "../../../../../../bazel-out/local-fastbuild/genfiles",
      "../../../../../../bazel-out/local-fastbuild/bin"
    ],
    "baseUrl": "../../../../../..",
    "paths": {
      "*": [
        "./*",
        "bazel-out/local-fastbuild/genfiles/*",
        "bazel-out/local-fastbuild/bin/*"
      ]
    },
    "preserveConstEnums": false,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "jsx": "react",
    "jsxFactory": "React.createElement",
    "noEmitOnError": false,
    "declaration": true,
    "stripInternal": true,
    "inlineSourceMap": true,
    "inlineSources": true,
    "sourceMap": false
  },
  "bazelOptions": {
    "workspaceName": "__main__",
    "target": "//src/shadowbox/model:model",
    "tsickle": false,
    "tsickleGenerateExterns": true,
    "tsickleExternsPath": "",
    "untyped": true,
    "typeBlackListPaths": [],
    "es5Mode": true,
    "manifest": "bazel-out/local-fastbuild/bin/src/shadowbox/model/model.es5.MF",
    "compilationTargetSrc": [
      "src/shadowbox/model/metrics.ts",
      "src/shadowbox/model/shadowsocks_server.ts",
      "src/shadowbox/model/user.ts"
    ],
    "disableStrictDeps": false,
    "allowedStrictDeps": [],
    "enableConformance": false,
    "nodeModulesPrefix": "node_modules"
  },
  "files": [
    "../../../../../../src/shadowbox/model/metrics.ts",
    "../../../../../../src/shadowbox/model/shadowsocks_server.ts",
    "../../../../../../src/shadowbox/model/user.ts"
  ],
  "compileOnSave": false,
  "extends": "../../../../../../src/shadowbox/tsconfig"
}

And I get compilation errors:

$ bazel build src/shadowbox/model:model
INFO: Found 1 target...
ERROR: /Users/fortuna/firehook/uproxy-cloud-install/src/shadowbox/model/BUILD:5:1: Compiling TypeScript (devmode) //src/shadowbox/model:model failed (Exit 1).
src/shadowbox/model/user.ts(35,16): error TS2304: Cannot find name 'IterableIterator'.
src/shadowbox/model/metrics.ts(17,104): error TS2304: Cannot find name 'Map'.
src/shadowbox/model/metrics.ts(35,26): error TS2304: Cannot find name 'Set'.

Which makes me believe it's ignoring the ES6 target and using ES5 instead.

ts_library fails when only composed of .d.ts files

You get the following error. As a temporary fix you can just include an empty .ts file

ERROR: /home/achew22/js/externs/BUILD:3:1: in ts_library rule //externs:externs: 
Traceback (most recent call last):
        File "/home/achew22/js/externs/BUILD", line 3
                ts_library(name = 'externs')
        File "/home/achew22/.cache/bazel/_bazel_achew22/b4046dd61443a6da2a0d424d121b9b4a/external/build_bazel_rules_typescript/internal/build_defs.bzl", line 116, in _ts_library_impl
                compile_ts(ctx, is_library = True, compile_acti..., <2 more arguments>)
        File "/home/achew22/.cache/bazel/_bazel_achew22/b4046dd61443a6da2a0d424d121b9b4a/external/build_bazel_rules_typescript/internal/common/compilation.bzl", line 199, in compile_ts                compile_action(ctx, inputs, outputs, tsconfig_json_es...)
        File "/home/achew22/.cache/bazel/_bazel_achew22/b4046dd61443a6da2a0d424d121b9b4a/external/build_bazel_rules_typescript/internal/build_defs.bzl", line 53, in compile_action
                ctx.action(progress_message = "Compiling Ty..., <6 more arguments>)
illegal argument in call to action: action outputs may not be empty.

npm install doesn't work on windows

because the npm binary lives in the root of the package, not under a bin directory like the linux package.
/cc @ocombe

Add bazel-rules topic to repository

It would be great to have a bazel-rules (and also bazel?) Topic on the repository, so that we can find it when listing projects with that topic:
https://github.com/search?q=topic%3Abazel-rules&type=Repositories

Upgrade to protobufjs 6

I spent quite a while tracing through an issue with protobufjs that stems from the fact that I had manually installed it, meaning it was at the latest version, 6, and tsc_wrapped apparently fails if it's on 6 instead of 5, in a way that seems...incredibly opaque to me. tsc_wrapped isn't even in the stack trace below(!!), but I did eventually track it down to that, and downgrading to 5 fixed the issue.

I unfortunately can't think of a way that would make this easier for past-Caleb to debug, but upgrading to protobufjs 6 would solve the specific problem regardless.

(As an aside, I find this all pretty weird that NPM/Yarn wouldn't yell at me about having incompatible versions being depended on, or just install both versions for the appropriate project. Otherwise, what's the point of semver and including versions at all? Maybe this is some basic thing that I just haven't experienced, but it seems crazy to me.)

$ bazel build src
INFO: Found 1 target...
ERROR: /Users/calebegg/Code/mta/src/BUILD.bazel:4:1: Compiling TypeScript (devmode) //src:src failed (Exit 1).
failed to load main  TypeError: Cannot read property 'resolve' of undefined
    at Object.<anonymous> (/Users/calebegg/Code/mta/node_modules/protobufjs/src/root.js:62:39)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Users/calebegg/Code/mta/node_modules/protobufjs/src/index-light.js:83:29)
    at Module._compile (module.js:570:32)
Target //src:src failed to build

Allow es5+esm output

Currently we always set --module=commonjs; this option should be free for the user to control.

tsconfig extending from other tsconfig doesn't work

We only include the tsconfig.json file the user specifies in the tsconfig attribute as inputs to a compilation. Need to also include any more tsconfig files it extends.

Error reporting when missing a node module

Currently with no node_modules you get something like

/build_bazel_rules_typescript/internal/tsc_wrapped/BUILD.bazel:26:1: Compiling TypeScript (devmode) @build_bazel_rules_typescript//internal/tsc_wrapped:tsc_wrapped failed (Exit 1)
failed to load main  TypeError: Path must be a string. Received undefined
    at assertPath (path.js:7:11)
    at Object.dirname (path.js:1324:5)
    at Module.load (module.js:483:45)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Object.<anonymous> (/home/nathan/.cache/bazel/_bazel_nathan/16731ad4c7c7062932200f437ef52271/execroot/__main__/bazel-out/host/bin/external/build_bazel_rules_typescript/internal/tsc_wrapped/tsc_loader.js:84:24)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)

Support TypeScript 2.4

Bazel version

Build label: 0.5.3-homebrew
Build target: bazel-out/darwin_x86_64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Jul 27 19:30:37 2017 (1501183837)
Build timestamp: 1501183837
Build timestamp as int: 1501183837

package.json deps:

"@types/node": "^8.0.19",
"typescript": "^2.4.2"

And I'm using node v7.7.1
I have a very minimal project that I set up following the guides from the README and I'm trying to compile the ts files but I receive this error when I run bazel build //src:code

ERROR: /private/var/tmp/_bazel_iliaidakiev/8d1bfde2a069f58cf456d9a87f138f67/external/build_bazel_rules_typescript/internal/tsc_wrapped/BUILD.bazel:26:1: Compiling TypeScript (devmode) @build_bazel_rules_typescript//internal/tsc_wrapped:tsc_wrapped failed (Exit 2).
external/build_bazel_rules_typescript/internal/tsc_wrapped/tsc_wrapped.ts(180,9): error TS2322: Type '{ getNewLine: () => string; getCanonicalFileName: (f: string) => string; args: string[]; newLine:...' is not assignable to type 'FormatDiagnosticsHost'.
  Object literal may only specify known properties, and 'args' does not exist in type 'FormatDiagnosticsHost'.
Target //src:code failed to build
Use --verbose_failures to see the command lines of failed build steps.

my tsconfig looks like:

{
  "compilerOptions": {
    "target": "es5",   
    "module": "commonjs",
    "outDir": "./built",
    "strict": true,
    "moduleResolution": "node",
    "baseUrl": "./src",
    "typeRoots": [
      "node_modules/@types"
    ]
  }
}

interoperate with rules_closure

It would be nice to have a ts_binary rule that turns ts_libraries into a single .js file.
Unless I miss something and there's already a way to do this?

Maybe with bazelbuild/rules_closure, it would be possible to optimized the output code using closure_js_binary.

strict_deps plugin is not installed in tsc_wrapped

The strict_deps plugin checks the imports of the compiled modules.
It should be enabled in tsc_wrapped (around here) to produce extra diagnostics.

Initial setup troubles

Following the instructions on the front page:

1. Which version of node rules should I use? It just says "latest" but doesn't say how to figure out what that should be.

2. Before you run anything you need a package.json, otherwise you get a big error [1].

3. That's enough to run yarn, but then after you try to use ts_library, you get another big error [2]. Alex says it's because you need a bazel run @yarn//:yarn -- add -D @bazel/typescript.

Error [1]:

$ bazel run @yarn//:yarn
ERROR: Skipping '@yarn//:yarn': no such package '@yarn//': Traceback (most recent call last):
	File "/usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_nodejs/internal/node_install.bzl", line 100
		ctx.file("yarn.sh", ("#!/bin/bash" + "".joi...])), ...)
	File "/usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_nodejs/internal/node_install.bzl", line 100, in ctx.file
		"".join(["\nROOT=\"$(dirname \"{}\")\"\n...])
	File "/usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_nodejs/internal/node_install.bzl", line 100, in "".join
		"\nROOT=\"$(dirname \"{}\")\"\nNODE=\"{}\"\nSCRIPT=\"{}\"\n(cd \"$ROOT\"; \"$NODE\" \"$SCRIPT\" \"$@\")\n".format(ctx.path(package_json), ctx.path(n...), ..."))
	File "/usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_nodejs/internal/node_install.bzl", line 106, in "\nROOT=\"$
		ctx.path(package_json)
Not a file: /usr/local/google/home/evanm/projects/devserver/package.json
WARNING: Target pattern parsing failed.
ERROR: no such package '@yarn//': Traceback (most recent call last):
	File "/usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_nodejs/internal/node_install.bzl", line 100
		ctx.file("yarn.sh", ("#!/bin/bash" + "".joi...])), ...)
	File "/usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_nodejs/internal/node_install.bzl", line 100, in ctx.file
		"".join(["\nROOT=\"$(dirname \"{}\")\"\n...])
	File "/usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_nodejs/internal/node_install.bzl", line 100, in "".join
		"\nROOT=\"$(dirname \"{}\")\"\nNODE=\"{}\"\nSCRIPT=\"{}\"\n(cd \"$ROOT\"; \"$NODE\" \"$SCRIPT\" \"$@\")\n".format(ctx.path(package_json), ctx.path(n...), ..."))
	File "/usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_nodejs/internal/node_install.bzl", line 106, in "\nROOT=\"$
		ctx.path(package_json)
Not a file: /usr/local/google/home/evanm/projects/devserver/package.json
INFO: Elapsed time: 1.233s
FAILED: Build did NOT complete successfully (0 packages loaded)
ERROR: Build failed. Not running target

Error [2]

$ bazel build :my_code
ERROR: Skipping ':my_code': error loading package '': Encountered error while reading extension file 'defs.bzl': no such package '@build_bazel_rules_typescript//': /usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_typescript must be an existing directory
WARNING: Target pattern parsing failed.
ERROR: error loading package '': Encountered error while reading extension file 'defs.bzl': no such package '@build_bazel_rules_typescript//': /usr/local/google/home/evanm/.cache/bazel/_bazel_evanm/f6cc45cea0037091838c829714de86cc/external/build_bazel_rules_typescript must be an existing directory
INFO: Elapsed time: 0.081s
FAILED: Build did NOT complete successfully (0 packages loaded)
    currently loading: 

sometimes need to `bazel clean --expunge`?

Seems related to local_repository, sometimes it's not the same as what's in node_modules/@bazel/typescript? Even though it's a symlink to there?

ts_library cannot depend on a genrule

This minimal example fails:

genrule(
  name = "foo_ts",
  outs = ["foo.ts"],
  cmd = "echo 'export const FOO = 1;' > $@",
)

ts_library(
  name = "foo",
  srcs = [":foo.ts"],
)

With error:

$ bazel build src/web_app:foo
INFO: Found 1 target...
ERROR: /usr/local/google/home/fortuna/firehook/uproxy-cloud-install/src/web_app/BUILD:37:1: output 'src/web_app/foo.js' was not created.
ERROR: /usr/local/google/home/fortuna/firehook/uproxy-cloud-install/src/web_app/BUILD:37:1: output 'src/web_app/foo.d.ts' was not created.
ERROR: /usr/local/google/home/fortuna/firehook/uproxy-cloud-install/src/web_app/BUILD:37:1: not all outputs were created or valid.
Target //src/web_app:foo failed to build

It seems the bazel rule identified the input somehow, but I think it didn't make it all the way to tsc.

Actual location of generated d.ts file outputs do not match expected with declarationDir

As per discussion in #30. Bazel expects the generated d.ts files to be siblings of the generated js files. The tsc/tsconfig declarationDir option throws this off, causing the ts_library rule to fail.

Packaging

The documented configuration (in README) will generate .js and .d.ts files in $WORKSPACE/bazel-bin/. This is a good first step for applications, but what about for modules that will be published to npm - how does rules_typescript fit in to that workflow?

One possibility is that ts_library could copy any package.jsons it finds in srcs to bazel-bin alongside the built files. Then, an author could do something like

cd bazel-bin/packages/my-library/
yarn publish

That could probably be wrapped in its own bazel rule/command, but 👶 👣 .

Ambient types are not automatically discovered

By default, TypeScript discovers ambient types under node_modules/@types/* to be resolvable. For example, a .ts file can just contain import * as fs from 'fs' and it works if the node typings are installed.

Under bazel the types must be explicitly referenced, eg.
/// <reference types="node"/>

It doesn't help to list the types in the tsconfig compilerOptions.types[] which is not surprising since IIUC that only restricts which types the compiler includes in resolution.

We noticed this yesterday in the Angular team (cc @matsko and @IgorMinar), independently reported in #30.

Demonstrate usage of protocol buffers

Should have type-safe access to generated protos.

We could use this in our own repo: currently proto objects are type any, eg

rules_typescript/internal/tsc_wrapped/worker.ts

Line 26 in 6456790

const workerpb = (function loadWorkerPb() {

https://github.com/dcodeIO/ProtoBuf.js/#usage-with-typescript seems like the obvious .d.ts code generator to use. This also implies that the library must use the protobuf.js generated runtime.

/cc @jart

Document what users need to do if they bring their own devserver

Things like

• Inject the livereload script referencing env['IBAZEL_LIVERELOAD_URL']
• Concat the files with eval() - we have examples in node and go
• Have the ibazel tag to make sure it doesn't get restarted on changes with ibazel run
  etc

/cc @gregmagolan

Bad error message when installed typescript version isn't compatible with tooling

I came across the following error when attempting to build the example with version 0.2.2:

ERROR: /private/var/tmp/_bazel_kylelehtinen/44fb04a4c0d5b92efea3ee928a865cfc/external/build_bazel_rules_typescript/internal/tsc
_wrapped/BUILD.bazel:26:1: Compiling TypeScript (devmode) @build_bazel_rules_typescript//internal/tsc_wrapped:tsc_wrapped failed (Exit 2).
external/build_bazel_rules_typescript/internal/tsc_wrapped/compiler_host.ts(361,5): error TS2322: Type 'string | undefined' isnot assignable to type 'string'.
  Type 'undefined' is not assignable to type 'string'.

Line 361 in compiler_host.ts invokes the typescript method 'readFile' which can return undefined, but the wrapper method here is typed only to return a string. When I updated the return type to include string or undefined the error went away and my sample typescript files were successfully built/transpiled.

I don't know much beyond that but thought I'd bring it up.

Duplicate identifier errors when importing something from @types

If I import something that I have @types for, I get Duplicate identifier errors:

For example, this code:

import * as electron from 'electron';
export function Hi() {
  console.log('hi');
}

Will result in errors like:

bazel-out/host/bin/external/io_bazel_rules_typescript/internal/tsc_wrapped.runfiles/yarn/installed/node_modules/@types/electron/index.d.ts(15,7): error TS2300: Duplicate identifier 'Point'.
bazel-out/host/bin/external/io_bazel_rules_typescript/internal/tsc_wrapped.runfiles/yarn/installed/node_modules/@types/electron/index.d.ts(20,7): error TS2300: Duplicate identifier 'Size'.
bazel-out/host/bin/external/io_bazel_rules_typescript/internal/tsc_wrapped.runfiles/yarn/installed/node_modules/@types/electron/index.d.ts(25,7): error TS2300: Duplicate identifier 'Rectangle'.
bazel-out/host/bin/external/io_bazel_rules_typescript/internal/tsc_wrapped.runfiles/yarn/installed/node_modules/@types/electron/index.d.ts(45,7): error TS2300: Duplicate identifier 'VibrancyType'.
bazel-out/host/bin/external/io_bazel_rules_typescript/internal/tsc_wrapped.runfiles/yarn/installed/node_modules/@types/electron/index.d.ts(456,7): error TS2300: Duplicate identifier 'AppPathName'.
...

If I remove the import, compilation finished successfully. This bug pretty much prevents me from using @types, and with #2 we are pretty much prevented from using any type declaration file.

named UMD re-write applies to .d.ts files for which we cannot know a module name

eg. node_modules/tsickle/declarations/tsickle.d.ts
we cannot re-write this as a named UMD import because we cannot know where the .js file will be loaded, in this case it's
node_modules/tsickle/src/tsickle.js

Absolute path imports

I had some problems with absolute imports.
Example: import A from 'proto/A';

My project layout is like this

/
/WORKSPACE
/BUILD.bazel
/app/
/app/BUILD.bazel
/app/proto
...
/app/index.ts

So to make it work, in index.ts, I have to import app/proto/A.
Is there any way to be able to just import from proto/A ?

terrible error if users rules_nodejs is too old

rules_typescript has a dependency on rules_nodejs at some version.

Due to bazelbuild/bazel#1943
users have to specify all the tags in their WORKSPACE so they are free to pick versions that don't work.

bazelbuild/bazel#2757 (comment) seems like a workaround: publish a repository_rule that installs our deps at the right tag.

tsconfig doesn't seem to be working

As instructed, I have this in my root BUILD:

exports_files(["tsconfig.json"])

and this in my package BUILD:

ts_library(
  name = "core",
  module_name = "material-motion",
  module_root = "src",
  srcs = glob(
    include = ["src/**/*.ts"],
    exclude = ["**/__tests__/*"],
  ),
  tsconfig = "//:tsconfig.json",
)

However, the options in my tsconfig aren't being respected. No matter what I do, I'm getting es5 output. Moreover, I can replace //:tsconfig.json with any garbage name, but it is silently ignored.

Here's //:tsconfig.json:

{
  "compilerOptions": {
    "declaration": true,
    "lib": [
      "es2015",
      "es2016",
      "es2017",
      "dom"
    ],
    "importHelpers": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "noImplicitAny": true,
    "noImplicitThis": true,
    "sourceMap": true,
    "strictNullChecks": true,
    "target": "es2015"
  },
  "bazelOptions": {
    "googmodule": true
  }
}

bazel build cannot find tsc.js

I am trying to use bazel with my typescript project and after setting up the basics as in the readme I get this error.

..........
INFO: Found 2 targets...
ERROR: /private/var/tmp/_bazel_a13575/0a014a13c52b9c9d10834f80d53a0b06/external/build_bazel_rules_typescript/internal/tsc_wrapped/BUILD.bazel:26:1: Compiling TypeScript (devmode) @build_bazel_rules_typescript//internal/tsc_wrapped:tsc_wrapped failed (Exit 1).
failed to load main  Error: Cannot find module 'typescript/lib/tsc.js'
  looked in:
   typescript/lib/tsc.js,
   /private/var/tmp/_bazel_a13575/0a014a13c52b9c9d10834f80d53a0b06/bazel-sandbox/149211111440408385/execroot/__main__/bazel-out/host/bin/external/build_bazel_rules_typescript/internal/tsc_wrapped/tsc.runfiles/typescript/lib/tsc.js,
   /private/var/tmp/_bazel_a13575/0a014a13c52b9c9d10834f80d53a0b06/bazel-sandbox/149211111440408385/execroot/__main__/bazel-out/host/bin/external/build_bazel_rules_typescript/internal/tsc_wrapped/tsc.runfiles/build_bazel_rules_typescript/node_modules/typescript/lib/tsc.js
    at Function.module.constructor._resolveFilename (/private/var/tmp/_bazel_a13575/0a014a13c52b9c9d10834f80d53a0b06/execroot/__main__/bazel-out/host/bin/external/build_bazel_rules_typescript/internal/tsc_wrapped/tsc_bin_loader.js:137:15)
    at Function.Module._load (module.js:417:25)
    at Object.<anonymous> (/private/var/tmp/_bazel_a13575/0a014a13c52b9c9d10834f80d53a0b06/execroot/__main__/bazel-out/host/bin/external/build_bazel_rules_typescript/internal/tsc_wrapped/tsc_bin_loader.js:149:24)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:393:7)
INFO: Elapsed time: 14.731s, Critical Path: 0.37s

WORKSPACE

load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")

git_repository(
    name = "build_bazel_rules_nodejs",
    remote = "https://github.com/bazelbuild/rules_nodejs.git",
    tag = "0.1.11", # check for the latest tag when you install
)

load("@build_bazel_rules_nodejs//:defs.bzl", "node_repositories")

node_repositories(package_json = ["//:package.json"])

local_repository(
    name = "build_bazel_rules_typescript",
    path = "node_modules/@bazel/typescript",
)

BUILD.bazel

package(default_visibility = ["//visibility:public"])

exports_files(["tsconfig.json"])

# NOTE: this will move to node_modules/BUILD in a later release
filegroup(
     name = "node_modules",
     srcs = glob(["node_modules/**"]),
)

package.json

...
  "devDependencies": {
    "@bazel/typescript": "0.2.x",
    "tsickle": "^0.25.0",
    "typescript": "2.4.2",

The file exists in the node_modules/typescript/lib folder.

Users have to add protobufjs to their devDependencies

because the worker protocol uses it to decode bazel requests.

We should instead publish a rules_typescript package to npm for users to depend on, so our internal deps don't leak this way.

Missing symbols with ts-protoc-gen

I'm working on getting ts-protoc-gen to compile with rules_typescript. First real project I've used with rules_typescript so it may be is likely something stupid I'm doing.

pcj:~/github/improbable-eng/ts-protoc-gen*bazel$ bazel build //src:src
ERROR: /Users/pcj/github/improbable-eng/ts-protoc-gen/src/BUILD:4:1: Compiling TypeScript (devmode) //src:src failed (Exit 1)
src/util.ts(48,49): error TS2304: Cannot find name 'Buffer'.
src/util.ts(49,14): error TS2304: Cannot find name 'Buffer'.
src/util.ts(52,17): error TS2304: Cannot find name 'process'.
src/util.ts(57,30): error TS2304: Cannot find name 'Buffer'.
src/util.ts(64,14): error TS2304: Cannot find name 'Buffer'.
src/js_service_index.ts(13,26): error TS2304: Cannot find name 'Buffer'.
src/js_service_index.ts(39,5): error TS2304: Cannot find name 'process'.
src/js_service_index.ts(39,30): error TS2304: Cannot find name 'Buffer'.
src/js_service_index.ts(42,5): error TS2304: Cannot find name 'process'.
src/ts_index.ts(14,26): error TS2304: Cannot find name 'Buffer'.
src/ts_index.ts(50,5): error TS2304: Cannot find name 'process'.
src/ts_index.ts(50,30): error TS2304: Cannot find name 'Buffer'.
src/ts_index.ts(53,5): error TS2304: Cannot find name 'process'.

Which made me think the ambient node types are missing, but they seem to be present:

pcj:~/github/improbable-eng/ts-protoc-gen*bazel$ bazel query //:* --output=label_kind | grep '@types/node'
source file //:node_modules/@types/node/package.json
source file //:node_modules/@types/node/index.d.ts
source file //:node_modules/@bazel/typescript/node_modules/@types/node/package.json
source file //:node_modules/@bazel/typescript/node_modules/@types/node/index.d.ts

Any pointers on how to approach it?

improbable-eng/ts-protoc-gen#24

ES6 output doesn't work

The ts_library rule has a typescript.es6_sources provider that claims to yield alternate .closure.js files intended to pass to bundling tools, but it doesn't actually write these outputs.

Import from project root doesn't resolve

The generated tsconfig.json is missing a pathmapping for * that points to bazel-bin.
So we don't find the .d.ts files when doing a "project absolute" import, eg. in this repo

import {Greeter} from 'examples/foo';

should work but doesn't.

/cc @vsavkin

Lacking documentation of ts_library parameters

The rule ts_library has a few parameters that are not documented in the README file: module_name, module_root, tsc, runtime.

They sound useful and it would be nice to have them explained in the documentation.

Can't run mocha on generated .js file

There's something off with the way bazel_typescript generates the modules. When I run mocha on one of the generated .js files, it can't find the __main__ dependencies:

./node_modules/mocha/bin/mocha bazel-out/local-fastbuild/bin/transports/transports_test.js

module.js:471
    throw err;
    ^

Error: Cannot find module '__main__/transports/transports'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at /private/var/tmp/_bazel_vini/2d5cfdef207760378b471079ca80358b/execroot/__main__/bazel-out/local-fastbuild/bin/transports/transports_test.js:16:22
    at Object.defineProperty.value (/private/var/tmp/_bazel_vini/2d5cfdef207760378b471079ca80358b/execroot/__main__/bazel-out/local-fastbuild/bin/transports/transports_test.js:5:17)
    at Object.<anonymous> (/private/var/tmp/_bazel_vini/2d5cfdef207760378b471079ca80358b/execroot/__main__/bazel-out/local-fastbuild/bin/transports/transports_test.js:11:3)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (modul

Top of the .js file:

$ cat bazel-out/local-fastbuild/bin/transports/transports_test.js
///  <reference types="mocha"/>
///  <reference types="node"/>
(function (factory) {
    if (typeof module === "object" && typeof module.exports === "object") {
        var v = factory(require, exports);
        if (v !== undefined) module.exports = v;
    }
    else if (typeof define === "function" && define.amd) {
        define("__main__/transports/transports_test", ["require", "exports", "assert", "stream", "__main__/transports/transports"], factory);
    }
})(function (require, exports) {
    "use strict";

And my BUILD:

ts_library(
    name = "transports_test",
    srcs = ["transports_test.ts"],
    deps = [
        ":model",
        ":transports",
    ],
    tsconfig = "//:tsconfig.json",
)

cleanup: allowNonHermeticRead should not be needed

@hansl has a repro:

TypeScript finds glob at node_modules/glob/index.js and not at @types/glob. It's related to symlinks - if we add an implementation for realpath in the compiler host in tsc_wrapped then it resolves correctly.

However, adding the realpath breaks the current check for nodeModulesPrefix.
For now we'll make a workaround of matching on /node_modules/ instead, so this issue is to go back and clean that up (and add a reproduction test)

Need to wait for yarn install to complete

It's possible for the first build to run before the node_modules directory is populated. Some output of the yarn_install action should be an input to later actions.

Sometimes get warning that TypeScriptCompile doesn't support workers

With .bazelrc setting
--strategy=TypeScriptCompile=worker
I sometimes see
WARNING: Worker strategy cannot execute this TypeScriptCompile action, because the action's execution info does not contain 'supports-workers=1'.
But it seems intermittent. Don't have a good repro yet.

Allow more npm repositories

Because npm_install is hardcoded to create a repository named "npm", it's impossible to have two projects inside the same workspace.

Investigate using rollup in devmode

Currently our prototype uses "concatjs" which bundles by simply concatenating files wrapped in eval().
However it requires we use a module format that doesn't depend on path information, which is "named AMD". This format is unusual, and if we do this it means our dependencies like rxjs have to do it too (if we want them inside the bundle)

@tbosch pointed out that we have to escape some characters in the input. Currently we do this with JSON.stringify although it could be much faster in go:

for _, b := range contents {
		switch b {
		case '\n':
			if _, err := out.Write([]byte("\\n")); err != nil {
				return err
			}
		case '\r':
			if _, err := out.Write([]byte("\\r")); err != nil {
				return err
			}
		case '\\', '\'':
			if _, err := out.Write([]byte{'\\'}); err != nil {
				return err
			}
			fallthrough
		default:
			if _, err := out.Write([]byte{b}); err != nil {
				return err
			}
		}
	}

In theory, rollup could also be fast, and it would let us accept commonjs inputs which is more normal.

tsetse should disallow self-assignment

similar to one of the first Error Prone checks we added to Java: http://errorprone.info/bugpattern/SelfAssignment

Add Windows CI

And make it green!

ts_declaration is not exposed

I couldn't figure out how to specify dependencies on .d.ts files.
I can't create a library of .d.ts files with ts_library. I tried creating a filegroup and adding as data or deps but it didn't work.

It seems that we need ts_declaration, but that's not available publicly. Is there a workaround?
It would be great to add an example that used .d.ts files.

@yarn//:yarn requires node installed locall

When using bazel run @yarn//:yarn yarn depends on a local node install rather than using the one downloaded by bazel. If no node is installed the command will error.

Don't require the tsconfig attribute on ts_library

We should default to an empty tsconfig.

Run yarn check --integrity at the right time

Any time the node_modules directory changes, we should run yarn check --integrity.

• catches issue with user having wrong yarn version installed
• prevents builds failing due to unexpected changes in node_modules (eg. user has installed something and not updated the yarn.lock)

currently we only do this when the repository_rule runs, and it's not re-run until the WORKSPACE changes.

Broken v0.1.1

After I upgraded to v0.1.1 from v0.1.0, I started getting errors in my build:

ERROR: /private/var/tmp/_bazel_fortuna/e17cba90bcda49718c709b4e8df956d9/external/build_bazel_rules_typescript/internal/tsc_wrapped/BUILD.bazel:26:1: Compiling TypeScript (devmode) @build_bazel_rules_typescript//internal/tsc_wrapped:tsc_wrapped failed (Exit 1).
Failed to find node binary __main__/external/nodejs/bin/node in manifest /private/var/tmp/_bazel_fortuna/e17cba90bcda49718c709b4e8df956d9/bazel-sandbox/769481833178162151/execroot/__main__/bazel-out/host/bin/external/build_bazel_rules_typescript/internal/tsc_wrapped/tsc.runfiles_manifest
bazel-out/host/bin/external/build_bazel_rules_typescript/internal/tsc_wrapped/tsc: line 103: /private/var/tmp/_bazel_fortuna/e17cba90bcda49718c709b4e8df956d9/bazel-sandbox/769481833178162151/execroot/__main__/bazel-out/host/bin/external/build_bazel_rules_typescript/internal/tsc_wrapped/tsc.runfiles_manifest: No such file or directory
Target //src/shadowbox:server failed to build

I believe the release may be broken. When I revert to the previous version, my target compiles again.