This commit fixes a bug whereby a Bazel project created by the
schematics would not compiled if project contains routing module.
It is missing a dependency on the router package.
PR Close#28141
* This is a follow-up to cd0451305a which fixes that "ngc-wrapped" from the "npm" workspace is always used if "angular" is fetched as an external dependency.
PR Close#28137
With the update to TypeScript 3.2.x, a big issue seems to have appeared for downstream Bazel users. If the downstream user still uses a lower TypeScript version, normal Bazel targets using the `ng_module` rule are still compiled with the correct/old TypeScript version (assuming they set the `node_modules` attribute properly).
But, if they build the previous Bazel targets by specifying them within a `ng_package` rule, the TypeScript version from the Angular `workspace` is being used for the replayed ESM5 compilation. This is because we resolve the replay compiler to `ngc_wrapped` or `tsc_wrapped` Bazel executables which are defined as part of the `angular` workspace. This means that the compilers are different if the downstream user uses `ngc-wrapped` from the `@npm` repository because the replayed compilation would use the compiler with `@ngdeps//typescript`.
In order to fix this, we should just use the compiler that is defined in the `@angular//BUILD.bazel` file. This target by defaults to the "@npm" workspace which is working for downstream users. This is similar to how it is handled for `tsc-wrapped`. `tsc-wrapped` works as expected for downstream users.
**Note**: This is not the ideal solution because ideally we would
completely respect the `compiler` option from the base `ng_module`, but
this is not possible in a hermetic way, unless we somehow accept the
`compiler` as an attribute that builds all transitive deps. This is
something we should explore in the future. For now, we just fix this in
a reasonable way that is also used for `tsc_wrapped` from the TypeScript
rules.
PR Close#28053
index.html needs to have the zone.js and the project bundle injected
using script tags. This used to be done explicitly by specifying a
new index.html but with `web_package` rule introduced in rules_nodejs,
it is now possible to perform the injection dynamically.
PR Close#27995
Incremental rebuilds is a fundamental part of the development
workflow. `@bazel/ibazel` should be added to the dev dependencies
of a Bazel project.
PR Close#28090
There are various e2e tests with the `_spec.ts` suffix in the Angular project. Currently the protractor Bazel rule does not pick up these files and just ignores them. Since underscore is commonly used, we should support this.
Needed for the conversion fo the `examples` to Bazel.
PR Close#28022
Project created by @angular/cli depends on Bazel at build time and
we should not assume that Bazel is available globally.
Instead, the project should specify an explicit dev dependency on
`@bazel/bazel`.
PR Close#28032
Instead of relying on implicit dependencies through Angular, the WORKSPACE
of the project should explicitly add rules_nodejs and rules_typescript so
it can better control the versions.
PR Close#28000
* Fixes that the flat module out files do not have a proper AMD module name on Windows. This is currently blocking serving a `ng_module` using the Bazel TypeScript `devserver` on Windows.
PR Close#27839
* Currently the protractor utils assume that the specified Bazel server runfile can be resolved by just using the real file system. This is not the case on Windows because the runfiles are not symlinked into the working directory and need to be resolved through the runfile manifest.
PR Close#27915
Currently when building a package on Windows, the typings re-export for secondary entry-points is not valid TypeScript. Similarly the metadata and the "package.json" files use non-posix paths and cause inconsistency within the NPM package.
For example:
_package.json_
```
"esm5": "./esm5\\core.js",
"esm2015": "./esm2015\\core.js",
```
_testing.d.t.s_ (of the `core` package)
```
export * from './testing\testing';
```
PR Close#27829
Due to an incorrect environment variable name, it's currently not possible to launch Protractor on Windows using the Bazel protractor rule.
PR Close#27850
This commit fixes a bug whereby the path of the entry_module is not
consistent with the workspace name, which does not permit dashes
in the name.
PR Close#27719
Relative imports in Typescript files only work when module_name is
defined in ts_library (when run in Node.js).
See issue https://github.com/bazelbuild/rules_typescript/issues/360
With that fixed, `ng test` now works.
`ng build` requires `node_modules` to be available in the project
directory, so it's not usable yet. Running `yarn` in project directory
does not work because of postinstall version check.
PR Close#27715
The default 10 items are often not enough to debug deeply nested compilation operations.
This PR is based on @martinprobst's http://cl/225528216.
PR Close#27678
In order to keep the bazel bin directory as clean as possible, we should not write definition files that are not relevant to a `ng_package` to an undesired location in the bazel bin directory. This currently just happens because we only filter out external definition files while we also should filter out definitions that aren't just in the current package.
The `packager.ts` file currently tries to write these files to the package, but fails because those are not inside of the current package. So the logic to create a relative path for the file fails, and the definition will be copied to a location like:
```js
// Notice the double "bazel-out" here.
C:\Users\Paul\_bazel_Paul\kn4tsvyh\execroot\angular_material\bazel-out\x64_windows-fastbuild\bin\src\bazel-out\x64_windows-fastbuild\bin\src\cdk
```
[See logic that causes this](4f9374951d/packages/bazel/src/ng_package/packager.ts (L105-L124)) (nothing wrong with that logic because it assumes that only paths from within the package are passed to it)
PR Close#27519
ngtsc now produces flat module index files when that option is enabled
in tsconfig, but Bazel still needs the output declared in order for them to
be passed through.
This fixes some tests which verify this behavior on Bazel.
FW-738 #resolve
PR Close#27655
When @angular/bazel is installed, a postinstall script is run to make sure that
the npm version is *exactly* the same as the Angular repository install by
Bazel. This check is overly stringent. Instead, it should enforce that the
version satisfies the range check instead. This is consistent with the range
defined in angular-cli/packages/schematics/angular/utility/latest-versions.ts.
This commit also fixes the Bazel workspace to use the same Rxjs version if it's
already installed.
PR Close#27526
This release of rules_typescript fixes a critical bug: typescript code
was not checked at all, including type-checking, tsetse, and strict deps
fixes#27569
PR Close#27586
`@angular/bazel` currently requires TypeScript 3.1.x as a peer dependency, but comes with `tsickle` as dependency. The current version of `tsickle` that is specified by `@angular/bazel` does not support TypeScript 3.1.x (which is a peer dependency) and therefore we need to make sure that `tsickle` works with the required TypeScript versions.
This change updates `tsickle` to the latest version that comes with b10fb6de0a in order to work with TypeScript 3.1.x.
PR Close#27402
Switch from Skylint to buildifier --lint - this is required for the Bazel 0.20 upgrade since Bazel no longer lets us use the embedded JDK to build and run Java programs, and Skylint is a Java program
PR Close#27489
If user has already installed Angular, Bazel should fetch the same
version. Otherwise, user will see an error in the post-install step
that performs version check.
PR Close#27495
Previously, Bazel/Blaze were only expecting .ngfactory.js and .ngsummary.js
files to be generated in legacy mode. ngtsc was attempting to write those
files, but they ended up being ignored at the Bazel level.
This commit causes Bazel to expect these files, and rearranges the logic
a little bit as the name 'include_ng_files' is now incorrect.
FW-514 FW-737 #resolve
PR Close#27483
This commit allows //packages/bazel/test/ngc-wrapped/... tests to run
under Ivy mode. To get them to pass, it addresses a problem with the
way the tests are configured: both test targets have sloppy .d.ts
dependencies configured, leading to many type errors being generated
in TypeScript for the .d.ts files.
Due to the way ngc directs TypeScript emit, it avoids type-checking
.d.ts files and thus this issue does not surface. ngtsc does a whole-
program emit which results in full .d.ts type-checking by default,
catching this configuration issue.
To fix this, skipLibCheck is added to the tsconfig.jsons for these
tests, which tells TypeScript to skip type-checking of the .d.ts files,
avoiding this problem in a similar way to ngc.
PR Close#27470
In some applications, developers define a `ts_library` that just consists of `d.ts` files (e.g. to type `module.id`; see: https://github.com/angular/material2/blob/master/src/module-typings.d.ts), and expect the `esm5.bzl` file to not throw an error like:
```
target.typescript.replay_params.outputs
struct' object has no attribute 'outputs'
```
The "replay_parameters" property will exist in that case, but is set to "None" because there is no action that should be replayed in favor of producing ES5 outputs. See: https://github.com/bazelbuild/rules_typescript/pull/326. Notice that this right now breaks similarly because an empty `struct()` is returned that does not have a property called `outputs`. [#326](https://github.com/bazelbuild/rules_typescript/pull/326) fixes that by being explicit that there is no _action_ at all.
PR Close#27401
Currently when building the `ng_package` multiple times, the old `ng_package` output will be copied over to the new `ng_package` content. Resulting in packages like `src/cdk/npm_package/npm_package/npm_package/AND_MORE`.
This happens because currently all TypeScript definition files are resolved from within the `binDir`. This is just wrong because it could then take up the `d.ts` files from the previous `ng_package` output. All typescript definitions that belong to the target package, should be resolved through Bazel and copied based on that computation.
Also fixes that `esm` files aren't written to the `ng_package` on Windows. This is because we try to flatten paths using the `path.delimiter` while the path is always using Posix delimiters (causing the paths to be incorrect)
PR Close#27200
* Currently when building the ES5 and ES2015 output, `ngc_wrapped` will fail because it tries to write the `fs.openSync` the tsickle output file at the same time. This causes a runtime exception in Windows and can be fixed by just writing the externs for ES5 mode to the proper ES5 "output root".
PR Close#27200
* Fixes that `ng_package` does not work generate UMD bundles on Windows because the `esm5/` files are not written to the output directory. This is because `rootDirs` and `rootDir` are posix paths and cause invalid relative paths when mixed with Windows backslash paths.
PR Close#27200
Keen Yee Liau
Paul Gschwendtner
Keen Yee Liau
Filipe Silva
Adam Plumer
Suguru Inatomi
Greg Magolan
Alex Eagle
Igor Minar
Alex Eagle
Alex Rickabaugh
Pete Bacon Darwin
Misko Hevery