This caused bazelbuild/rules_typescript#117

We should reject executions of npm_install that have floating, non-pinned versions, as it leads to non-hermetic behavior.

We have a monorepo with a vendored node_modules tree. If we evaluate bazel for this codebase, our ideal use would be to allow depending on individual modules in library targets. This would let our build take advantage of bazel's sandboxing and knowledge of dependencies to vastly reduce the work done, while maintaining reproducibility.

These rules appear to discourage fine-grained dependencies on modules, which will result in lots of wasted builds whenever a dependency is added, updated, or removed. Any suggestions on how to handle our use case / info on planned changes that might make it easier?

package.json

  "scripts": {
    "prepublish": "bazel build ...",

bazel run @yarn//:yarn
hangs because the prepublish command calls bazel from within bazel, the second command then hangs waiting for the first to complete.

/cc @evmar

Because we set rootPath = project_dir and then TS reads into the bazel-projectname symlink recursively and spends 20s stat'ting files.

Workaround is to include in .bazelrc:

build --symlink_prefix=/

thanks for debugging it, @hansl

API should be like

jasmine_node_test(
    name = "test",
    srcs = ["foo.js", ":rule_that_produces_js"],
    data = [":some_nodejs_binary_rule"],
)

Ideally we should have a way to share this code. (tricky because rules_typescript lives in google internal repo and rules_nodejs does not)

If a module is declared in workspace A

ts_library(name = "a_lib", module_name = "a")

then consumed in workspace B:

ts_library(name = "b_lib", deps = ["@a//:a_lib"])

import {} from 'a';

it looks like this won't work because our module mapping feature only accounts for workspace name in nodejs runtime, not at type-check time:
https://github.com/bazelbuild/rules_typescript/blob/master/internal/common/module_mappings.bzl#L101

See here: https://github.com/mattmoor/rules_nodejs-1/tree/express-example

The http example works:

$ bazel run :http
INFO: Analysed target //:http (0 packages loaded).
INFO: Found 1 target...
Target //:http up-to-date:
  bazel-bin/http_bin.sh
  bazel-bin/http
INFO: Elapsed time: 0.232s, Critical Path: 0.01s
INFO: Build completed successfully, 1 total action

INFO: Running command line: bazel-bin/http
Server running at http://127.0.0.1:8000/

However, the express version doesn't:

$ bazel run :express
INFO: Analysed target //:express (0 packages loaded).
INFO: Found 1 target...
Target //:express up-to-date:
  bazel-bin/express_bin.sh
  bazel-bin/express
INFO: Elapsed time: 0.240s, Critical Path: 0.01s
INFO: Build completed successfully, 1 total action

INFO: Running command line: bazel-bin/express
failed to load main  TypeError: Cannot set property 'o' of undefined
    at Object.<anonymous> (/home/mattmoor/rules_nodejs/examples/express/node_modules/debug/src/node.js:85:22)
    at Module._compile (module.js:635:30)
    at Object.Module._extensions..js (module.js:646:10)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Module.require (module.js:579:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/mattmoor/rules_nodejs/examples/express/node_modules/debug/src/index.js:9:20)
    at Module._compile (module.js:635:30)
ERROR: Non-zero return code '1' from command: Process exited with status 1

I'm assuming this simple example works (I'm not a Node.js guy), I am following this.

It is confusing that program has a WORKPACE, but rollup does not.

Can you make the rollup example self-contained / consistent?

I was able to do this by:

1. copy WORKSPACE from program.
2. rewrite BUILD to drop example/rollup/ before foo.js.
3. rewrite rollup.bzl to replace //example/rollup with //:rollup

I want the config files to be available for npm during runtime
Here is my BUILD.bazel file

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

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

nodejs_binary(
    name = "client-gen-service1",
    # Ordinarily this defaults to //:node_modules
    node_modules = "@foo//:node_modules",
    data = [":src/server.js",
            ":config/default.json",":config/dev.json"],
    entry_point = "__main__/client-gen/client-gen-service/src/server.js"
)

But when I run
bazel run :client-gen-service1 getting the following error

INFO: Running command line: bazel-bin/client-gen/client-gen-service/client-gen-service1
WARNING: NODE_ENV value of 'dev' did not match any deployment config file names.
WARNING: See https://github.com/lorenwest/node-config/wiki/Strict-Mode
WARNING: No configurations found in configuration directory:/private/var/tmp/_bazel_tagarwal/ea14abbe46cd7e70648aa164711eaeb5/execroot/__main__/bazel-out/darwin-fastbuild/bin/client-gen/client-gen-service/client-gen-service1.runfiles/__main__/config
WARNING: To disable this warning set SUPPRESS_NO_CONFIG_WARNING in the environment.

I have a project that compile fine with Webpack. However I get error TS2307: Cannot find module 'deepmerge'. -like errors when building with Bazel. I use the same tsconfig and node_modules, etc.

It seems that this package (deepmerge) doesn't come with types. In this case (deepmerge), there is @types/deepmerge available. Installing it fixes things more or less. But it is not the case for every package out there. (plus I can't make @types/deepmerge work correctly.... so let's assume it doesn't exist for now)

It's odd that things build with Webpack, but not with Bazel. Here's a sample repo that build as is. But remove or comment the test/test.d.ts file, and the build fails:
https://github.com/yohcop/rules-typescript-test

> bazel build test
INFO: Analysed target //test:test (0 packages loaded).
INFO: Found 1 target...
ERROR: /tmp/test/test/BUILD:3:1: Compiling TypeScript (devmode) //test:test failed (Exit 1)
test/test.ts(1,20): error TS2307: Cannot find module 'deepmerge'.

The tsconfig.json has "noImplicitAny": false of course. Typescript should be able to handle those js-only packages since 2.1 or something like that. I suspected some of the overridden tsconfig compilerOptions, maybe module. In the end I couldn't make things work without the declare module 'deepmerge'; in test.d.ts.

Any ideas? Or suggestions for me to try? Thanks!

ci.bazel.build uses Python 3 now, hence rules_nodejs are no pass tests: https://ci.bazel.build/blue/rest/organizations/jenkins/pipelines/Global/pipelines/rules_nodejs/runs/182/nodes/19/log/?start=0

We also use these from other repositories to load sources for the browser.

Hi,

this repo has a webhook installed for:
https://source.developers.google.com/webhook/github

Is this still needed and for what? I can't see rules_nodejs listed on source.bazel.build, nor on source.developers.google.com.

(I'm just trying to clean up our webhook / integration structure for the bazelbuild org and repos a bit.)

Cheers,
Philipp

The Bazel idiom is that files should be listed in srcs[] while other rules are listed in deps[].

I'd expect rollup_bundle's attributes to be

        "srcs": attr.label_list(allow_files = [".js"]),
        "deps": attr.label_list(),

/cc @gregmagolan

Attempting to build a React project with Bazel. I was able to get it working if I handle the node_modules myself, but when I try to have Bazel auto-manage them I run into errors. Was wondering if you could point me in the right direction.

WORKSPACE

git_repository(
  name = "build_bazel_rules_nodejs",
  remote = "https://github.com/bazelbuild/rules_nodejs.git",
  tag = "0.3.1",
)

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

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

npm_install(
    name = "noodles",
    package_json = "//:package.json",
)

BUILD.bazel

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

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

nodejs_binary(
  name = "react",
  node_modules = "@noodles//:node_modules",
  entry_point = ".bin/react-scripts"
)

bazel run :react start throws an error

Error: Cannot find module '/private/var/tmp/_bazel_name/f3f45320aadac9e5bae9fe1a19fa2c7e/execroot/__main__/bazel-out/darwin-fastbuild/bin/react.runfiles/__main__/package.json'
    at Function.Module._resolveFilename (module.js:513:15)
    at Function.Module._load (module.js:463:25)
    at Module.require (module.js:556:17)
    at require (internal/module.js:11:18)
    at getPublicUrl (/private/var/tmp/_bazel_name/f3f45320aadac9e5bae9fe1a19fa2c7e/external/noodles/node_modules/react-scripts/config/paths.js:34:19)
    at Object.<anonymous> (/private/var/tmp/_bazel_name/f3f45320aadac9e5bae9fe1a19fa2c7e/external/noodles/node_modules/react-scripts/config/paths.js:61:14)
    at Module._compile (module.js:612:30)
    at Object.Module._extensions..js (module.js:623:10)
    at Module.load (module.js:531:32)
    at tryModuleLoad (module.js:494:12)
ERROR: Non-zero return code '1' from command: Process exited with status 1

whereas bazel run :react install gives a valid response

Unknown script "install".
Perhaps you need to update react-scripts?

So it seems that the node_modules were correctly installed but the script I'm referencing can't seem to find the project files where it usually looks. Is this simply a consequence of react-scripts not being familiar with the file locations or am I missing something necessary in the build file? Any help in the right direction would be appreciated.

edit: example repo here

Currently these rules are experimental because we expect breaking changes.

This tracking issue will be resolved when we commit to the public API.

Bazel's karma.conf is hardcoded to jasmine. How might we enable this to be replaced with other popular options (e.g. mocha or jest)?

The simplest implementation may be to add it to the ts_web_test BUILD rule, but then every package would need to manually specify a framework.

Can we introspect it from package.json? If not, perhaps it can be passed as an option to ts_setup_workspace.

Thanks to @buchgr for debugging this.

The npm_install rule runs npm install and the resulting package.json file is not stable:

buchgr@buchgr0:~/code$ diff package1.json package2.json 
5c5
<   "_integrity": "sha1-2oEVQQzCps14cUVRrJKkLd4mdnY=",
---
>   "_integrity": "sha1-R2/vTKo8o0qUVsI0pBPoRMV9gcc=",

Since the value is different, it's not sufficient to just sort the keys.

As a result, all actions that rely on this toolchain get cache misses since the input doesn't have a stable hash.

in google3 we use headless chrome
via https://github.com/karma-runner/karma-chrome-launcher#headless-chromium-with-puppeteer

when the user does ibazel run :my_web_test
because ibazel is the reporter.

When run with bazel test or ibazel test, then we do open the window, assuming that users are running the test only once so they would like to debug.

/cc @vikerman

bazel run @yarn//:yarn fails on windows with
C:/path/to/output-base/external/yarn/yarn.sh is not recognized as an internal or external command, operable program or batch file

The workaround is

bazel build @yarn//:yarn
sh -c $(bazel info output_base)/external/yarn/yarn.sh

/cc @dslomov

Like https://github.com/bazelbuild/rules_go/tree/master/go/tools/gazelle

we should be able to generate/maintain BUILD files automatically from TypeScript sources.
We do this internally at google.

Hey! I'm interested in merging more functionality from https://github.com/dropbox/rules_node into this set of rules.

One nice thing from Dropbox's rules is that we support building either arbitrary JS bundles with node_build and webpack in particular with webpack_build.

For context, we wanted to use bazelbuild/rules_nodejs to build the frontend of our livegrep fork with webpack, but ended up using our open source rules instead because there's no out-of-the-box support for running webpack builds in rules_nodejs (source).

Would it make sense to add those kinds of rules to rules_nodejs? One of the concerns is obviously that developers would have to take care to make their node builds hermetic, and webpack in particular has its own set of pitfalls (e.g. you have to disable symlink following).

See workaround here: https://github.com/alexeagle/rules_karma/blob/f539baf2b7f509c5201f369ec963b127e71657e1/internal/karma_test.bzl#L47

fyi - this is evident on my build host where there's no node available in the environment. The build fails with:

no such package '@npm_json//': npm_install failed: (/usr/bin/env: 'node': No such file or directory

I note that external/nodejs/bin/npm starts with #!/usr/bin/env node, which, if I understand bazel philosophy correctly, seems like a problem.

I have a BUILD that looks like this:

ts_library(
  name = "playground",
  module_name = "dgitize-playground",
  module_root = "src",
  srcs = glob(
    include = ["src/**/*.ts", "src/**/*.tsx"],
    exclude = ["**/__tests__/*"],
  ),
  deps = ["//packages/core"],
  tsconfig = "//:tsconfig.json",
)

ts_devserver(
  name = "devserver",
  deps = [
    "//:node_modules/react/umd/react.development.js",
    "//:node_modules/react-dom/umd/react-dom.development.js",
    "//:node_modules/jsxstyle/jsxstyle.amd.js",
    "//:node_modules/jsxstyle-utils/jsxstyle-utils.amd.js",
    ":playground",
  ],
  entry_module = 'dgitize_root/packages/playground/src/index',
  serving_path = "/dist/bundle.js",
  static_files = ["site/index.html"],
)

:core uses argument destructuring, so TypeScript required that I install tslib. Then, the JS served by ts_devserver complained that I didn't import tslib. I was able to resolve that by adding this dep to ts_devserver:

"//:node_modules/tslib/tslib.js",

Is including tslib something ts_devserver should do automatically?

This means that rules_nodejs requires node to be installed on the system before it is able to do anything.

$ bazel run @yarn//:yarn
INFO: Analysed target @yarn//:yarn (6 packages loaded).
INFO: Found 1 target...
Target @yarn//:yarn.sh up-to-date (nothing to build)
INFO: Elapsed time: 7.735s, Critical Path: 0.01s
INFO: Build completed successfully, 1 total action

INFO: Running command line: [redacted]/a3cee343d71b0f2101c79d88
606a48aa/external/yarn/yarn.sh
yarn install v0.22.0
warning [email protected]: License should be a valid SPDX license expression
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
warning "@angular/[email protected]" has incorrect peer dependency "@angular/[email protected]
ta.5-4ec5e28".
[4/4] Building fresh packages...
$ ngc -p angular.tsconfig.json
/usr/bin/env: node: No such file or directory
error Command failed with exit code 127.

It may be be possible to invoke ngc's index.js from the included nodejs and not have this problem but by invoking it directly it uses the /usr/bin/env node shebang.

Currently these rules support accessing node_modules from some place instantiated within the source tree. This is consistent with Node.js user expectations and makes sense to offer users as an option.

However, requiring node_modules within the source tree is inconsistent with the way just about all other Bazel tools leverage WORKSPACE, which enables a user to effectively clone the repo and bazel {build,test} ... with no additional setup.

Essentially, we offer a Node.js idiomatic option, but not a Bazel idiomatic option.

I would like to propose one small addition to this repository, which is to offer a mechanism by which users can choose to instantiate the :node_modules filegroup during WORKSPACE evaluation.

The idea would be that users could still opt to use today's approach, where they instantiate node_modules outside of WORKSPACE, then expose and reference it via:

=== BUILD ===
# Expose
filegroup(name = "node_modules", srcs = glob(["node_modules/**/*"]))

# Reference
nodejs_binary(
    name = "bar",
    node_modules = "//:node_modules",
    ...
)

Alternately users could write:

=== WORKSPACE ===
# Expose (or yarn_install)
npm_install(
    name = "foo",
    packages = ":package.json",  # Or the lock-file
)

=== BUILD ===
# Reference
nodejs_binary(
    name = "bar",
    node_modules = "@foo//:node_modules",
    ...
)

I have a working prototype of this here that I've validated with my express "hello world" app. I believe beyond the new rule definitions I only needed one small change to internal/node.bzl.

If you'd be receptive to adding this as an option, I'd be receptive to trying to clean it up and get it upstreamed. WDYT?

@jonjohnsonjr @davidstanke @pubref @samertm FYI

https://skydoc.bazel.build/

would be a nice way to keep the documentation inline in the sources.
However, it's extra work to generate and publish the documentation site.

I don't have a simple example on hand, but I can make one if needed.
It seems that the dev_server packages requirejs and then all of my modules fine.

But then when I do require(["__main__/my/index"]), this tries to pull a ton of other dependencies, that are normally under node_modules, by making many requests to the dev_server. It wouldn't be much of an issue if my project used one or two packages, I could include them manually in my index.html file, but with tens of dependencies, it is a challenge.

What is the recommended way of doing this? I can try to maintain a genrule that concat together the files my project needs, output a node_deps.js file and have a <scritp src="node_deps.js">. I would also need to wrap things correctly for require js actually.

Is it in the plans that the dev server would also pack and serve files from node_modules?

When a source tree is really large, editors can't load the entire repository.

Users should be able to open a subdirectory of the repository, without losing features like type-checking and auto-completion referencing symbols declared outside that subdirectory.

In other languages, bazel supports it with a plugin:
https://blog.bazel.build/2016/06/10/ide-support.html

We might want something similar to create a tsconfig.json section that gives the needed pathMappings to teach typescript how to find the bazel-out/.../path/to/dependency/api.d.ts files needed.

I am trying to write a test rules which uses a nodejs binary. My rule currently looks like the following error:

/private/var/tmp/_bazel_pweaver/b8912c475ba6eed2e1170c9c188c1211/bazel-sandbox/3295380895294116077/execroot/abstract/bazel-out/darwin_x86_64-fastbuild/bin/app/app_tslint_test.runfiles/main/bazel_rules/tslint: line 93: /private/var/tmp/_bazel_pweaver/b8912c475ba6eed2e1170c9c188c1211/bazel-sandbox/3295380895294116077/execroot/abstract/bazel-out/darwin_x86_64-fastbuild/bin/app/app_tslint_test.runfiles/main/external/io_bazel_rules_typescript_node/bin/node: No such file or directory

When I add a transitive runfile declaration on the nodejs binary I get a target (rule class of 'nodejs_binary') doesn't have provider 'runfiles'. But shouldn't the nodejs_binary be exporting it's runfiles?

def _tslint_test_impl(ctx):
  """
  Implementation for tslint__test Skylark rule.
  """

  srcs = ctx.files.srcs
  tslint = ctx.attr.tslint.files.to_list()[0]
  tslint_bin = ctx.executable.tslint_bin
  exe = ctx.outputs.executable

  args = ["#!/bin/sh\nexec", tslint_bin.short_path,
         "-c ", tslint.short_path]
  args += [src.short_path for src in srcs]
  
  ctx.file_action(
      executable=True,
      output=exe,
      content=" ".join(args))
  return struct(
      files=set([exe]),
      runfiles=ctx.runfiles(
        files=[exe, tslint] + srcs,
        transitive_files=ctx.attr.tslint_bin.runfiles,
        )
      )

We encourage users to use the locking mechanism in their package manager, but we don't check that the dependencies match the versions in the lock file for each run.

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.

Not sure what to do about npm.

Currently, users provide the full path to a local js file to use it as an entry point, including the workspace name. It's a bit of extra typing, but it's workable.

This gets a bit more cumbersome for nodejs_binary using entry points that aren't at fixed locations e.g. from other rules in macros. (FWIW this isn't an issue for rules e.g. ctx.workspace_name + "/" + ctx.file.foo.path, but it's unrelated because rules can't call other rules.)

Below is an example: we have an intermediary rule which outputs a js file, and we want the nodejs_binary to use it as an entry point. But the macro doesn't know the path to the js file, so we have to get the user to specify the path.

def foo_rule(
        name,
        # "workspace_name/path/to/BUILD/directory/"
        current_path,
        visibility = None):

    # Intermediary rule outputs "{name}.js".
    intermediary_name = "%s.intermediary" % name
    intermediary_rule(
        name = intermediary_name,
    )

    # Nodejs rule combines current path with known output name
    nodejs_binary(
        name = name,
        data = [
            "@//:node_modules",
            intermediary_name,
        ],
        entry_point = "%s%s.js" % (current_path, intermediary_name),
        visibility = visibility,
    )

Proposal

Add the current path to the node module resolver's list of resolve paths.

The above entry point can be changed to a relative path:

    nodejs_binary(
        # ...
        entry_point = "%s.intermediary.js" % name,

Caveats

Files supplied in data would clash with node_modules. Convoluted example:

    nodejs_binary(
        # ...
        data = [
            "@//:node_modules",
            "some_node_module/foo.js",
        ],
        entry_point = "example.js",
    )

const foo = require('some_node_module/foo.js'); // Which one?

Alternatives considered

Change entry_point to be attr.label instead of attr.string

Ruled out because this would break references to node_modules.

Split entry_point into two attributes, one attr.label for local references, one attr.string for node_modules references

Not as straightforward for users.

Split nodejs_binary into two rules, one for local entry points, one for node_modules entry points

Not as straightforward for users.

It should be possible to mark some sources, including nodejs_binary, and create a TreeArtifact that is a publishable npm artifact.

rules_nodejs forces Node.js v6. However, I'd like to use v8.
It would be great to have a way to specify which version I'm using.

This is a tracking issue to get ts_library to work with closure_js_proto_library deps.
Currently, when a closure_js_proto_library rule is provided as a dep to a ts_library rule, the ts_library fails to build with the error that the dep is "neither a TypeScript nor a JS producing rule." However, closure_js_proto_library does generate a JS output at bazel-genfiles/path/to/<target_name>.js.

CI tools like Circle base their error reporting on JUnit. It allows them to visualize logs like this:

https://circleci.com/gh/material-motion/material-motion-js/1025

Can we add reporters: ['junit', 'progress'] to karma.conf?

(Not sure which repo this belongs in, please redirect if there's somewhere better.)

To handle more compile-to-js languages, we will need a shared provider that they can all use. This is alluded to in this repo in a comment.

Currently, if you include a ts_library in the bootstrap of a ts_web_test, the d.ts is delivered to the browser, which does nothing. If the ts_library is added to the deps, the file is included in the karma manifest, but never imported by anything, so the module "side effects" never happen.

The workaround is to ensure that any file you want to run like this ends with spec so that it gets included along with the rest of the tests. This convention is pretty non-obvious, so having a more explicit API would improve ergonomics.

So if node is looking for
pkgA
we fail to find that in the manifest because the entry is
pkgA.js.
Then we don't give any starting path for node to look in. Somehow we need to do the manifest lookup lower down, when node is stat'ing files on disk.

/cc @dslomov

The design section in the readme explains why Bazel is only being used as the build tool and not as the packager manager.
I think there are some assumptions which are made as to why this is ok and the builds will still be reproducible and hermetic (for example the versions declared for dependencies in package.json are fixed and not latest).
These assumptions should probably be documented (and maybe also enforced where possible) so that users can try to follow and enforce them (by guidelines).
cc @damienmg

This example does not correctly demo how the ts_deverser build rule should work

@damienmg is this something I can get from http://ci.bazel.build ? I see some windows references in https://github.com/bazelbuild/continuous-integration/search?utf8=%E2%9C%93&q=windows&type= so I think you have some support there?

While working through the Angular Bazel Example: https://github.com/alexeagle/angular-bazel-example, I ran into the following issue.

Getting an error when running the following:
$ bazel run @yarn//:yarn -- add -dev @bazel/typescript

- returns -

INFO: Found 1 target...
Target @yarn//:yarn up-to-date:
  /private/var/tmp/_bazel_jlhart/4d66c7e7add1c81f2c0e9cd3fac1ef83/execroot/__main__/bazel-out/darwin_x86_64-fastbuild/bin/external/yarn/yarn
INFO: Elapsed time: 7.538s, Critical Path: 0.00s

INFO: Running command line: /private/var/tmp/_bazel_jlhart/4d66c7e7add1c81f2c0e9cd3fac1ef83/execroot/__main__/bazel-out/darwin_x86_64-fastbuild/bin/external/yarn/yarn add -dev @bazel/typescript
yarn add v0.22.0
error Missing list of packages to add to your project.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
ERROR: Non-zero return code '1' from command: Process exited with status 1.

I was able to get around it by running:
$ yarn

I later saw in another post to use:
$ bazel run @yarn//:yarn -- add -D @bazel/typescript
which seems to work, but reporting out the error I received above per @alexeagle

FYI
I ran $ npm install @bazel/ibazel but could not $ ibazel build src
I finally figured out I had to $ ./node_modules/.bin/ibazel build src to get command to run.

jasmine_node_test is exposed publicly and quite useful, but there's no documentation about how to use it.

Is it possible for rules_typescript to compile ReactJS? I tried a bit and found that it can generate the bundle.js but in the devserver it's not running.

Here is the generated bundle.js:

(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__/streamline/fe/src/entry", ["require", "exports", "react", "react-dom"], factory);
    }
})(function (require, exports) {
    "use strict";
    Object.defineProperty(exports, "__esModule", { value: true });
    var React = require("react");
    var ReactDOM = require("react-dom");
    var App = function () {
        return (React.createElement("div", null,
            React.createElement("p", null, "Hello world!")));
    };
    ReactDOM.render(React.createElement(App, null), document.getElementById('app'));
});

Looks like the anonymous factory function was never called. Both requirejs and amd was installed with yarn.

Any help? Thanks.