Within an Angular package, it can happen that there are
entry-points which do not contain features that belong into
an `@NgModule` or need metadata files to be generated.
For example: the `cdk`, `cdk/testing` and `cdk/coercion`
entry-points. Besides other entry-points in the `cdk`
package, those entry-points do not need metadata to
be generated and no not use the `ng_module` rule.
Currently the "ng_package" rule properly picks up such
entry-points and builds bundles, does downleveling etc.
The only thing it misses is that no `package.json` files
are generated for the entry-point. This means that consumers
will not be able to use these entry-points built with "ts_library"
(except accessing the individual bundlings explicitly).
The "ng_package" rule should follow the full APF specification
for such entry-points. Partially building bundles and doing the
downleveling is confusing and a breaking issue.
The motifivation of supporting this (besides making the
rule behavior consistent; the incomplete output is not
acceptable), is that using the "ng_module" rule does
not make sense to be used for non-Angular entry-points.
Especially since it depends on Angular packages to
be specified as Bazel action inputs just to compile
vanilla TypeScript with `@angular/compiler-cli`.
PR Close#32610
BREAKING CHANGE:
Angular bazel users using protractor_web_test_suite from @angular/bazel npm package should now switch to the @bazel/protractor npm package.
This should impact very few users and the user's that are impacted have a very easy upgrade path to switch to fetching the protractor_web_test_suite rule via the @bazel/protractor npm package.
PR Close#32485
This commit switches the default value of the enableIvy flag to true.
Applications that run ngc will now by default receive an Ivy build!
This does not affect the way Bazel builds in the Angular repo work, since
those are still switched based on the value of the --define=compile flag.
Additionally, projects using @angular/bazel still use View Engine builds
by default.
Since most of the Angular repo tests are still written against View Engine
(particularly because we still publish VE packages to NPM), this switch
also requires lots of `enableIvy: false` flags in tsconfigs throughout the
repo.
Congrats to the team for reaching this milestone!
PR Close#32219
This option makes ngc behave as tsc, and was originally implemented before
ngtsc existed. It was designed so we could build JIT-only versions of
Angular packages to begin testing Ivy early, and is not used at all in our
current setup.
PR Close#32219
The API of `@microsoft/api-extractor` changed in a minor version which is causes an error when using dts flattening downstream.
API wil be updated on master https://github.com/angular/angular/pull/32185
PR Close#32187
There has been a regression where enabling rollup treeshaking causes errors during runtime because it will drop const access which will always evaluate to true or false. However, such `const` in `@angular/core` cannot be dropped because their value is changed when NGCC is run on `@angular/core`
VE
```
const SWITCH_IVY_ENABLED__POST_R3__ = true;
const SWITCH_IVY_ENABLED__PRE_R3__ = false;
const ivyEnabled = SWITCH_IVY_ENABLED__PRE_R3__;
```
Ivy (After NGCC)
```
const SWITCH_IVY_ENABLED__POST_R3__ = true;
const SWITCH_IVY_ENABLED__PRE_R3__ = false;
const ivyEnabled = SWITCH_IVY_ENABLED__POST_R3__;
```
FESM2015
```
load(path) {
/** @type {?} */
const legacyOfflineMode = this._compiler instanceof Compiler;
return legacyOfflineMode ? this.loadFactory(path) : this.loadAndCompile(path);
}
```
ESM2015
```
load(path) {
/** @type {?} */
const legacyOfflineMode = !ivyEnabled && this._compiler instanceof Compiler;
return legacyOfflineMode ? this.loadFactory(path) : this.loadAndCompile(path);
}
```
From the above we can see that `ivyEnabled ` is being treeshaken away when generating the FESM bundle which is causing runtime errors such as `Cannot find module './lazy/lazy.module.ngfactory'` since in Ivy we will always load the factories.
PR Close#32069
nodejs rules 0.34.0 now includes protractor_web_test_suite rule (via new @bazel/protractor rule) so we switch to that location for that rule in this PR so that /packages/bazel/src/protractor can be removed in a future PR
this PR also brings in node toolchain support which was released in nodejs rules 0.33.0. this is a prerequisite for RBE for mac & windows users
bazel schematics also updated with the same. @bazel/bazel 0.28.1 npm package includes transitive dep on hide-bazel-files so we're able to remove an explicit dep on that as well.
PR Close#31824
This switches all Angular targets to be built with the same Angular compiler architecture (c.n. Ivy) that the Angular indexer uses. This eliminates issues with cross-references to transitive dependencies not being generated because of the way such dependencies are loaded by the legacy compiler arch.
PR Close#31786
This commit bumps the heap size of node/ngc under bazel to 4 GB instead of
the previous 2 GB. This brings it in sync with what the TS compiler uses
in g3, and fixes a bug where ngc would crash with OOM in worker mode.
PR Close#31784
Switch back to passing a custom bazel host instead of rewriting one that
is passed to `compile` now that the Angular indexer is stable.
Revert "feat(bazel): allow passing and rewriting an old bazel host"
This reverts commit 0a4c1c8f803a65f5c156af90e67f7d7d68ebc7f8.
PR Close#31496
This is needed in g3 where the translation system is sensitive to the full path of the output.
For Bazel users, we don't want this because it would force them to
disable a Bazel option that prevents using the deprecated ctx.new_file
API
PR Close#31410
Updates the decision made in #31341; this is for the Angular indexer
inside Google. The indexer currently passes (and ngc-wrapped#compile
accepts) a bazel host to use, but because many methods are overwritten
specially for Angular compilation a better approach is to pass an old
bazel compiler host and siphon methods needed off of it before creating
a new host. This enables that.
PR Close#31381
after update to rules_nodejs 0.32.1, @types are no longer automatically discovered by ngc-wrapped (which uses parts of ts_library) so this test needed updating so that the types files it generates is added as an explicit dep
PR Close#31325
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)
@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazelbuild/rules_nodejs#802
also updates to rules_rass commit compatible with rules_nodejs 0.32.0
PR Close#31325
ctx.actions.declare_file now used in @angular/bazel ng_module rule as ctx.new_file is now deprecated. Fixes error:
```
File "ng_module.bzl", line 272, in _expected_outs
ctx.new_file(ctx.genfiles_dir, (ctx.label.name ..."))
Use ctx.actions.declare_file instead of ctx.new_file.
Use --incompatible_new_actions_api=false to temporarily disable this check.
```
This can be worked around with incompatible_new_actions_api flag but may as well fix it proper so downstream doesn't require this flag due to this code.
Also, depset() is no longer iterable by default without a flag. This required fixing in a few spots in @angular/bazel.
fix: foo
PR Close#31325
Enable users to pass a custom Bazel CompilerHost to use for an Angular
compilation. This supports users who must override the TypeScript
compiler host.
PR Close#31341
These files have not been formatted properly, due to issues in the
`gulp format*` tasks. See previous commits (or #31295) for more details.
PR Close#31295
No longer uses docker in order to pull down the toolchain configs
for remote build execution. We don't need to make docker a prerequisite
for working on the Angular repository since we can leverage the checked-in
toolchain configurations from the `@bazel-toolchains` repository.
PR Close#31251
after update to rules_nodejs 0.32.1, @types are no longer automatically discovered by ngc-wrapped (which uses parts of ts_library) so this test needed updating so that the types files it generates is added as an explicit dep
PR Close#31019
Brings in ts_library fixes required to get angular/angular building after 0.32.0:
typescript: exclude typescript lib declarations in node_module_library transitive_declarations
typescript: remove override of @bazel/tsetse (+1 squashed commit)
@npm//node_modules/foobar:foobar.js labels changed to @npm//:node_modules/foobar/foobar.js with fix for bazelbuild/rules_nodejs#802
also updates to rules_rass commit compatible with rules_nodejs 0.32.0
PR Close#31019
ctx.actions.declare_file now used in @angular/bazel ng_module rule as ctx.new_file is now deprecated. Fixes error:
```
File "ng_module.bzl", line 272, in _expected_outs
ctx.new_file(ctx.genfiles_dir, (ctx.label.name ..."))
Use ctx.actions.declare_file instead of ctx.new_file.
Use --incompatible_new_actions_api=false to temporarily disable this check.
```
This can be worked around with incompatible_new_actions_api flag but may as well fix it proper so downstream doesn't require this flag due to this code.
Also, depset() is no longer iterable by default without a flag. This required fixing in a few spots in @angular/bazel.
fix: foo
PR Close#31019
Under Bazel, we don't yet support Stylus and Less, and thus we should not offer the users to generate applications which are known not to work.
Closes#31209
PR Close#31234
* Updates buildifier to a version that also comes with windows binaries.
* Fixes a few new formatting/lint warnings
* Removes the `args-order` warning because it is no longer a warning.. and is now part of the formatter.
PR Close#31112
The generated Bazel workspace by the `@angular/bazel` builder should
use the latest stable NodeJS version. This is necessary because some
packages like `selenium-webdriver` which are part of the default bazel
setup in order to support `ng e2e` depend on a minimum NodeJS version
of `10.15.0`.. This means that running e2e tests in a plain new bazel CLI
project (`ng new {projectName} --collection=@angular/bazel`) errors.
```
command.
(error selenium-webdriver@4.0.0-alpha.3: The engine "node" is incompatible with
this module. Expected version ">= 10.15.0". Got "10.13.0"
error Found incompatible module
)
```
PR Close#31088
Before this change, user's tsconfig.json is cloned and some options
controlled by Bazel are removed otherwise Bazel would complain about:
```
WARNING: your tsconfig.json file specifies options which are overridden by Bazel:
- compilerOptions.target and compilerOptions.module are controlled by downstream dependencies, such as ts_devserver
- compilerOptions.typeRoots is always set to the @types subdirectory of the node_modules attribute
- compilerOptions.rootDir and compilerOptions.baseUrl are always the workspace root directory
```
Since the warning has been removed in rules_typescript/8d8d398, there's no
need to clone and backup tsconfig.json
PR Close#30877
* entry_point attribute of nodejs_binary & rollup_bundle is now a label
* symlinking of node_modules for yarn_install temporarily disabled (except for integration/bazel) until the fix for https://github.com/bazelbuild/bazel/issues/8487 makes it into a future bazel release
PR Close#30627
nodejs rules 0.30.1 has new feature to symlink node_modules with yarn_install and bazel 0.26.0 includes new managed_directories feature which enables this
PR Close#30627
_compile_action should take a list since we compute it within one node in the build graph
This needs to be cleaned up since Bazel is getting stricter with
disallowing iteration over depsets
PR Close#30600
Removing the sandbox improves build time by almost 40%.
For a hello world (ng new) application:
ng build with sandbox: 22.0 seconds
ng build without sandbox: 13.3 seconds
PR Close#30460
Preserve compatibility with rollup_bundle rule.
Add missing npm dependencies, which are now enforced by the strict_deps plugin in tsc_wrapped
PR Close#30370
After this PR is merged, maintainers no longer need to update .bazelrc
file, toolchain and platform related flags for RBE builds and tests
(unless there is a breaking change in Bazel related to those flags).
Maintainers just need to update the pin of @bazel-toolchains repo
regularly in the packages/bazel/package.bzl file according to
https://releases.bazel.build/bazel-toolchains.html to include the
latest checked-in toolchain configs. If rbe_autoconfig() cannot find
appropriate toolchain configs for the version of Bazel in the version of
@bazel_toolchains repo that is currently used by this project, it will pull
down the container and generate the configs on the fly as the beginning
of the build/test.
PR Close#29336
Instead of launching a Node.js process that in turn spawns Bazel binary,
the Builder could now directly spawn the native binary. This makes the
bootup process slightly more efficient, and allows the Builder to
control spawn options. This works with both Bazel and iBazel.
PR Close#30306
When `ng add` is invoked independently of `ng new`, a node installation
of `@angular/bazel` is performed by the CLI before invoking the
schematic. This step appends `@angular/bazel` to the `dependencies`
section of `package.json`. The schematics then appends the same package
to `devDependencies`.
This leads to the warning:
```
warning package.json: "dependencies" has dependency "@angular/bazel" with
range "^8.0.0-beta.13" that collides with a dependency in "devDependencies"
of the same name with version "~8.0.0-beta.12"
```
PR Close#30072
`ng build` by default builds the prodapp because there is not
a dev build in Bazel. This PR restores the `--prod` to do the
same to prevent achitect from showing missing config error.
PR Close#30005
Template type-checking is enabled by default in the View Engine compiler.
The feature in Ivy is not quite ready for this yet, so this flag will
temporarily control whether templates are type-checked in ngtsc.
The goal is to remove this flag after rolling out template type-checking in
google3 in Ivy mode, and making sure the feature is as compatible with the
View Engine implementation as possible.
Initially, the default value of the flag will leave checking disabled.
PR Close#29698
Currently for Angular Bazel projects, NGC needs to be run in the
"postinstall" NPM script in order to generate required summary files.
We need to update the postinstall `tsconfig` to not check/re-build the
`@angular/core` schematic code which has transitive dependencies
which are only available inside of a CLI project. As this is not guaranteed
to be the case with Angular Bazel projects, we need to make sure that
we don't check/re-build these files.
PR Close#29876
Fix the following error with future Bazel version:
```
Invalid label: invalid target name 'internal/npm_package:npm_package.bzl': target names may not contain ':'
```
PR Close#29777
`NodeJsSyncHost` is no longer provided by BuilderContext in
architect v2, and its usage caused subtle path resolution issues
in Windows.
This PR cleans up `@angular/bazel` builder to use all native path
and fs methods.
PR Close#29796
* fixes prodmode issue in integration/bazel
BREAKING CHANGE:
@bazel/typescript is now a peerDependency of @angular/bazel so user's of @angular/bazel must add @bazel/typescript to their package.json
PR Close#29508
https://github.com/angular/angular-cli/pull/13780 changes the project
layout for the e2e application. It is no longer a separate project
and the e2e directory is now located alongside the existing project.
This commit updates Bazel scheamtics to support both old and new project
layout.
PR Close#29318
`api-extractor` binary is required for external consumers of `ng_module` that want to use the `bundle_dts` flag.
This also sets a different api-exttractor binary to use for ng_module, based if it's internal or external.
PR Close#29202
`ng_module` will now include an `src/r3_symbol.d.ts` when compiling the core package under `ngc` togather with `dts bundling`, This is due that `ngcc` relies on this file to be present, but the `r3_symbols` file which is not part of our public api.
With this change, we can now ship an addition dts file which is flattened.
PR Close#28884
This commit modifies the Bazel builder to copy the Bazel WORKSPACE and
BUILD.bazel files to the project root directory before invoking Bazel.
This hides the Bazel files from users.
PR Close#29110
`ng build` should produce a bundle that could be readily deployed to
a web server, similar to the behavior of current `ng build` with
webpack.
Note that in Bazel, there is no `ng build` for dev bundles. Instead,
users are expected to run `ts_devserver`.
Closes https://github.com/angular/angular/issues/28877
PR Close#29136
This will make the debugging output go away
DEBUG: Rule 'io_bazel_rules_sass' modified arguments {"sha256": "6caffb8277b3033d6b5117b77437faaa6cd3c6679d6d6c81284511225aa54711"}
PR Close#28994
This commit adds a postinstall step to the package.json generated by the
schematics to generate ng summary files needed for AOT. Summary files
are not published in npm packages.
PR Close#28850
Since rxjs is no longer built from source in Bazel schematics, the
minimum version ought to be at least 6.4.0.
This commit adds function to bump the version in package.json.
PR Close#28841
Currently setting `enableIvy` to true runs a hybrid mode of `ngc` and `ngtsc`. This is counterintuitive given the name of the flag itself.
This PR makes the `true` value equivalent to the previous `ngtsc`, and `ngtsc` becomes an alias for `true`. Effectively this removes the hybrid mode as well since there's no other way to enable it.
PR Close#28616
Since we build and publish the individual packages
using Bazel and `build.sh` has been removed, we can
safely remove the `rollup.config.js` files which are no
longer needed because the `ng_package` bazel rule
automatically handles the rollup settings and globals.
PR Close#28646
Under Bazel, some compilerOptions in tsconfig.json are controlled by
downstream rules. The default tsconfig.json causes Bazel to print out
warnings about overriden settings.
This commit makes a backup of the original tsconfig.json and removes
tsconfig settings that are controlled by Bazel.
As part of this fix, JsonAst utils are refactored into separate package
and unit tests are added.
PR closes https://github.com/angular/angular/issues/28034
PR Close#28674
This enabled dts flattening in the final distrubutable package.
Notes:
- For the time being this is an opt-in feature via the `ng_module` attribute `bundle_dts`, however in the near future this will be turned on by default.
- This only supports the legacy compiler `ngc`, as `ngtsc` emits namespaced imports `import * as __` from local modules which is not supported for the time being by API Extractor. See: https://github.com/Microsoft/web-build-tools/issues/1029
Ref: TOOL-611
PR Close#28588
The ultimate goal of this commit is to make use of fileNameToModuleName to
get the module specifier to use when generating an import, when that API is
available in the CompilerHost that ngtsc is created with.
As part of getting there, the way in which ngtsc tracks references and
generates import module specifiers is refactored considerably. References
are tracked with the Reference class, and previously ngtsc had several
different kinds of Reference. An AbsoluteReference represented a declaration
which needed to be imported via an absolute module specifier tracked in the
AbsoluteReference, and a RelativeReference represented a declaration from
the local program, imported via relative path or referred to directly by
identifier if possible. Thus, how to refer to a particular declaration was
encoded into the Reference type _at the time of creation of the Reference_.
This commit refactors that logic and reduces Reference to a single class
with no subclasses. A Reference represents a node being referenced, plus
context about how the node was located. This context includes a
"bestGuessOwningModule", the compiler's best guess at which absolute
module specifier has defined this reference. For example, if the compiler
arrives at the declaration of CommonModule via an import to @angular/common,
then any references obtained from CommonModule (e.g. NgIf) will also be
considered to be owned by @angular/common.
A ReferenceEmitter class and accompanying ReferenceEmitStrategy interface
are introduced. To produce an Expression referring to a given Reference'd
node, the ReferenceEmitter consults a sequence of ReferenceEmitStrategy
implementations.
Several different strategies are defined:
- LocalIdentifierStrategy: use local ts.Identifiers if available.
- AbsoluteModuleStrategy: if the Reference has a bestGuessOwningModule,
import the node via an absolute import from that module specifier.
- LogicalProjectStrategy: if the Reference is in the logical project
(is under the project rootDirs), import the node via a relative import.
- FileToModuleStrategy: use a FileToModuleHost to generate the module
specifier by which to import the node.
Depending on the availability of fileNameToModuleName in the CompilerHost,
then, a different collection of these strategies is used for compilation.
PR Close#28523
This commit fixes a bug whereby recompilation occurs every time `yarn ng build`
or `yarn bazel build ...` is invoked.
This is a temporary solution until # https://github.com/bazelbuild/bazel/issues/7026
is fixed.
PR Close#28675
`multi_sass_binary` rules is reinstated in rules_sass v1.17.0
and it is a better solution than list comprehension currently used
because it handles imports correctly.
PR Close#28669
With #28594 we refactored the `@angular/compiler` slightly to
allow opting out from external symbol re-exports which are
enabled by default.
Since symbol re-exports only benefit projects which have a
very strict dependency enforcement, external symbols should
not be re-exported by default as this could grow the size of
factory files and cause unexpected behavior with Angular's
AOT symbol resolving (e.g. see: #25644).
Note that the common strict dependency enforcement for source
files does still work with external symbol re-exports disabled,
but there are also strict dependency checks that enforce strict
module dependencies also for _generated files_ (such as the
ngfactory files). This is how Google3 manages it's dependencies
and therefore external symbol re-exports need to be enabled within
Google3.
Also "ngtsc" also does not provide any way of using external symbol
re-exports, so this means that with this change, NGC can partially
match the behavior of "ngtsc" then (unless explicitly opted-out).
As mentioned before, internally at Google symbol re-exports need to
be still enabled, so the `ng_module` Bazel rule will enable the symbol
re-exports by default when running within Blaze.
Fixes#25644.
PR Close#28633
FileType objects are deprecated. They are not required for specifying valid file types for rule attributes, a list of strings can be used instead.
PR Close#28583
Adds `--no-sandbox` in order to disable the sandbox when running Protractor through Bazel. Enabling the sandbox causes Chrome to crash under certain environments.
PR Close#28557
The logic to create additional files needed for Bazel are currently
hosted in `ng new`. Such files include the main.*.ts files needed
for AOT and a different angular.json to use Bazel builder, among others.
This commit refactors the logic into `ng add` so that it can be used to
perform the same modifications in an existing project. Users could do so
by running `ng add @angular/bazel`.
With this change, `ng new` effectively becomes an orchestrator that runs
the original `ng new` followed by `ng add @angular/bazel`.
PR Close#28436
Currently we depend on the "rules_webtesting" version that is
installed by "rules_typescript//:package.bzl". This version of
the webtesting rules comes with a very old version of Chromium
and the `chromedriver` that does not support capturing console
errors properly (with stack traces). Since we have a few e2e
tests that depend on console output (e.g. playground/src/source-map),
we need to make sure that these tests can pass upon Bazel
migration.
PR Close#28490
This commit fixes a bug in the Bazel builder in which the path to Bazel
executable is constructed using the project path. For non-default
project, the node_modules directory is actually one level above the
project path.
This PR fixes the bug by resolving node_modules with require.resolve().
It requires @bazel/bazel v0.22.1 because previous versions do not have
index.js or main field in package.json and would cause node module
resolution to fail.
This has been tested with both bazel and ibazel.
PR Close#28478
Builder for `@angular/bazel` schematics should not expect bazel/ibazel
to be on the PATH. It should instead invoke the local executable
installed by yarn/npm.
PR Close#28303
Users should be able to add Bazel workspace to an existing project.
The current approach assumes that the schematics is working on the same
tree as that of ng-new, which includes the top-level directory. Instead,
the schematic should work on the tree rooted at `appRoot` to enable
Bazel files to be added to existing project.
This change uses the newly implemented ScopedTree
a0ac4b0e3d
to achieve this.
NOTE: The version of `@angular-devkit/schematics` that is installed is
used to run the `@angular/bazel` schematic. Even if a different version
is used in the schematic itself, it has no effect.
Therefore, the *latest* Angular CLI should be used to generate the
files. As of this commit, the latest version is @angular/cli@7.3.0-rc.0
PR Close#28349
yarn install was disabled in ng-new for Bazel schematics because
Bazel manages its own node_modules dependencies and therefore
there is no need to install dependencies twice.
However, the first yarn install is needed for `ng` commands to work,
most notably `ng build`.
This commit restores the original behavior.
PR Close#28381
The current build workflow depends on cross workspace dependency by
installing angular-cli as a Bazel repository. This is not ideal because
it introduces separate node_module directories other than the one
installed by Angular through the yarn_install rule (ngdeps).
This commit removes angular-cli from the Bazel workspace and installs
rollup and @angular-devkit/build-optimizer locally.
PR Close#28215
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
Paul Gschwendtner
Greg Magolan
Alan Agius
Miško Hevery
Alex Rickabaugh
Filipe Silva
Igor Minar
Ayaz Hafiz
George Kalpakas
Alex Eagle
Keen Yee Liau
Jeremy Elbourn
Bowen Ni
crisbeto
Keen Yee Liau
Xin Gao
Brandon Roberts
Yun Peng
Rado Kirov
Marc Laval
Matias Niemelä
Wassim Chegham
Adam Yi
Vladimir Moskva
Daniel Ruf
Adam Plumer
Suguru Inatomi