Skip to content

Commit

Permalink
docs: minor update for readibility and formating
Browse files Browse the repository at this point in the history
  • Loading branch information
evahowe committed Oct 19, 2020
1 parent 29901c3 commit 2a0cc20
Show file tree
Hide file tree
Showing 3 changed files with 26 additions and 31 deletions.
24 changes: 11 additions & 13 deletions docs/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,15 +16,13 @@ This JavaScript support lets you build and test code that targets a JavaScript r

## Scope of the project

This repository contains an orthogonal set of rules which covers an opinionated toolchain for JavaScript development. When requesting a new rule, describe your use case, why it's important, and why you can't do it with the existing rules. This is because we have limited resources to maintain additional rules.
This repository contains an orthogonal set of rules which covers an opinionated toolchain for JavaScript development. If you would like to request a new rule, please open a [feature request](https://github.com/bazelbuild/rules_nodejs/issues/new), describe your use case, why it's important, and why you can't do it within the existing rules. Then the maintainers can decide if it is within the scope of the project and will have a large enough impact to warrant the time required to impliment.

The repository accepts contributions in terms of bug fixes or implementing new features in existing rules. If you're planning to implement a new rule, please strongly consider opening a [feature request](https://github.com/bazelbuild/rules_nodejs/issues/new) first so the project's maintainers can decide if it belongs to the scope of this project or not.

For rules outside of the scope of the projects we recommend hosting them in your GitHub account or the one of your organization.
If you would like to write a rule outside the scope of the projects we recommend hosting them in your GitHub account or the one of your organization.

## Design

Most bazel rules include package management. That is, the `WORKSPACE` file installs your dependencies as well as the toolchain. In some environments, this is the normal workflow, for example in Java, Gradle and Maven are each both a build tool and a package manager.
Most bazel rules include package management. That is, the `WORKSPACE` file installs both your dependencies and toolchain at the same time. For example, in Java, Gradle and Maven they each install both a build tool and a packagae at the same time.

In nodejs, there are a variety of package managers and build tools which can interoperate. Also, there is a well-known package installation location (`node_modules` directory in your project). Command-line and other tools look in this directory to find packages. So we must either download packages twice (risking version skew between them) or point all tools to Bazel's `external` directory with `NODE_PATH` which would be very inconvenient.

Expand All @@ -38,10 +36,10 @@ Both NPM and Yarn have a lockfile, which ensures that dependencies only change w

References:

- npm: https://docs.npmjs.com/files/package-lock.json
- yarn: https://yarnpkg.com/lang/en/docs/yarn-lock/
- npm: [https://docs.npmjs.com/files/package-lock.json](https://docs.npmjs.com/files/package-lock.json)
- yarn: [https://yarnpkg.com/lang/en/docs/yarn-lock/](https://yarnpkg.com/lang/en/docs/yarn-lock/)

Note that https://github.com/bazelbuild/rules_nodejs/issues/1 will take the guarantee further: by using the lockfile as an input to Bazel, the nodejs rules can verify the integrity of the dependencies. This would make it impossible for a build to be non-reproducible, so long as you have the same lockfile.
Note that [https://github.com/bazelbuild/rules_nodejs/issues/1](https://github.com/bazelbuild/rules_nodejs/issues/1) will take the guarantee further: by using the lockfile as an input to Bazel, the nodejs rules can verify the integrity of the dependencies. This would make it impossible for a build to be non-reproducible, so long as you have the same lockfile.


## Quickstart
Expand All @@ -67,7 +65,7 @@ $ cd my_workspace
Next we install some development tools.
For this example, we'll use Babel to transpile our JavaScript, Mocha for running tests, and http-server to serve our app.
This is just an arbitrary choice, you probably already have some tools you prefer.
These are arbitrary choices, you may use whatever are your favorites.
```sh
$ npm install @babel/core @babel/cli @babel/preset-env http-server mocha domino
Expand All @@ -80,7 +78,7 @@ Let's run these tools with Bazel. There are two ways to run tools:
In this example we use the auto-generated rules.
First we need to import them, using a load statement.
So edit BUILD.bazel and add:
So edit `BUILD.bazel` and add:
```python
load("@npm//@babel/cli:index.bzl", "babel")
Expand All @@ -90,8 +88,8 @@ load("@npm//http-server:index.bzl", "http_server")
> This shows us that rules_nodejs has told Bazel that a workspace named @npm is available
> (think of the at-sign like a scoped package for Bazel).
> rules_nodejs will add index.bzl files exposing all the binaries the package manager installed
> (the same as the content of the node_modules/.bin folder).
> rules_nodejs will add `index.bzl` files exposing all the binaries the package manager installed
> (the same as the content of the `node_modules/.bin folder`).
> The three tools we installed are in this @npm scope and each has an index file with a .bzl extension.
Next we teach Bazel how to transform our JavaScript inputs into transpiled outputs.
Expand Down Expand Up @@ -150,7 +148,7 @@ Add a `serve` entry to the scripts in `package.json`:
> ibazel is the watch mode for bazel.
>
> Note that on Windows, you need to pass `--enable_runfiles` flag to Bazel.
> That's because Bazel creates a directory where inputs and outputs both appear together, for convenience.
> That's because Bazel creates a directory where inputs and outputs both conveniently appear together.
Now we can serve the app: `npm run serve`

Expand Down
31 changes: 14 additions & 17 deletions packages/typescript/install.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,15 +32,15 @@ We also produce JS code which can be loaded faster (using named AMD module forma

## Installation

Add a devDependency on `@bazel/typescript`
Add a `devDependency` on `@bazel/typescript`

```sh
$ yarn add -D @bazel/typescript
# or
$ npm install --save-dev @bazel/typescript
```

Watch for any peerDependency warnings - we assume you have already installed the `typescript` package from npm.
Watch for any `peerDependency` warnings - we assume you have already installed the `typescript` package from npm.

Create a `BUILD.bazel` file in your workspace root. If your `tsconfig.json` file is in the root, use

Expand All @@ -61,9 +61,9 @@ Make sure to remove the `--noEmit` compiler option from your `tsconfig.json`. Th

## Self-managed npm dependencies

We recommend you use Bazel managed dependencies but if you would like
We recommend you use Bazel managed dependencies, but if you would like
Bazel to also install a `node_modules` in your workspace you can also
point the `node_repositories` repository rule in your WORKSPACE file to
point the `node_repositories` repository rule in your `WORKSPACE` file to
your `package.json`.

```python
Expand Down Expand Up @@ -112,14 +112,14 @@ nodejs_binary(
)
```

See https://github.com/bazelbuild/rules_nodejs#dependencies for more information on
See [https://github.com/bazelbuild/rules_nodejs#dependencies](https://github.com/bazelbuild/rules_nodejs#dependencies) for more information on
managing npm dependencies with Bazel.

## Customizing the TypeScript compiler binary

An example use case is needing to increase the NodeJS heap size used for compilations.

Similar to above, you declare your own binary for running tsc_wrapped, e.g.:
Similar to above, you declare your own binary for running `tsc_wrapped`, e.g.:

```python
nodejs_binary(
Expand All @@ -141,9 +141,9 @@ nodejs_binary(
then refer to that target in the `compiler` attribute of your `ts_library` rule.

Note that `nodejs_binary` targets generated by `npm_install`/`yarn_install` can include data dependencies
on packages which aren't declared as dependencies. For example, if you use [tsickle] to generate Closure Compiler-compatible JS, then it needs to be a `data` dependency of `tsc_wrapped` so that it can be loaded at runtime.
[tsickle]: https://github.com/angular/tsickle
on packages which aren't declared as dependencies. For example, if you use [tsickle](https://www.npmjs.com/package/tsickle) to generate Closure Compiler-compatible JS, then it needs to be a data dependency of `tsc_wrapped` so that it can be loaded at runtime.

[tsickle](https://github.com/angular/tsickle)

## Usage

Expand Down Expand Up @@ -227,7 +227,7 @@ This is for a couple reasons:

- help ensure that downstream rules which access default outputs will not require
a cascading re-build when only the implementation changes but not the types
- make you think about whether you want the devmode (named UMD) or prodmode outputs
- make you think about whether you want the `devmode` (named `UMD`) or `prodmode` outputs

You can access the JS output by adding a `filegroup` rule after the `ts_library`,
for example
Expand Down Expand Up @@ -331,18 +331,15 @@ Since this is an extension to the vanilla TypeScript compiler, editors which use
}
```
to `tsconfig.json` will fix the imports for the common case of using absolute paths.
See [path mapping] for more details on the paths syntax.
See [path mapping](https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping) for more details on the paths syntax.

Similarly, you can use path mapping to teach the editor how to resolve imports
from `ts_library` rules which set the `module_name` attribute.

### Notes

If you'd like a "watch mode", try [ibazel].
If you'd like a "watch mode", try [ibazel](https://github.com/bazelbuild/bazel-watcher).

At some point, we plan to release a tool similar to [gazelle] to generate the
BUILD files from your source code.
At some point, we plan to release a tool similar to [gazelle](https://github.com/bazelbuild/bazel-gazelle) to generate the
`BUILD` files from your source code.

[gazelle]: https://github.com/bazelbuild/rules_go/tree/master/go/tools/gazelle
[ibazel]: https://github.com/bazelbuild/bazel-watcher
[path mapping]: https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping
2 changes: 1 addition & 1 deletion packages/typescript/internal/devserver/ts_devserver.bzl
Original file line number Diff line number Diff line change
Expand Up @@ -199,7 +199,7 @@ ts_devserver = rule(
},
doc = """ts_devserver is a simple development server intended for a quick "getting started" experience.
Additional documentation at https://github.com/alexeagle/angular-bazel-example/wiki/Running-a-devserver-under-Bazel
Additional documentation [here](https://github.com/alexeagle/angular-bazel-example/wiki/Running-a-devserver-under-Bazel)
""",
)

Expand Down

0 comments on commit 2a0cc20

Please sign in to comment.