Our style guide includes formatting conventions. Instead of wasting time in reviewing PRs discussing things like indenting, and to avoid later deltas to fix bad formatting in earlier commits, we want to enforce these in the build.
The intent in this change is to fail the build as quickly as possible in travis, so those sending a PR immediately know they should run clang-format and update their commit. When running locally, we want users to know about formatting, but they may not want to act on it immediately, until they are done working. For this reason, it is only a warning outside of the continuous build.
This is done by having a check-format task which should run on most local builds, and an enforce-format task only run by travis.
- Allow pub (build|serve) to specify mode
- Update pubbuild.js & pubserve.js to allow the caller to provide a `mode` value.
- Update settings to allow the di benchmark to be transformed to run statically.
* `npm install` now does a full install; auxiliary installation steps
have been integrated into the `postinstall` script.
* Updated developer docs `DEVELOPER.md` accordingly; also added
instructions to dev docs for performing full tests (via `npm test`) --
same as those run on Travis.
* Reorg in tests so that JS tests can run without a Dart env.
Partly fixes#945 **under the assumption that when running JS tests
locally, `ChromeCanary` is the desired browser to use**. Note that CI
tests (Travis) still uses `DartiumWithWebPlatform` across the board
(Maybe because ChromeCanary isn't being installed?)
Fixes#1012.
Closes#1010
Limitations because of preview status (see #960):
- does not yet use ShadowDOM
- does not use a builtin conditional like `if`
- uses a temporary bower repository
Closes#943
This adds a unit test to the transpiler. Existing tests are themselves transpiled to ES5, which makes it impossible to do some kinds of assertions. For example, this will be useful to repro https://github.com/angular/angular/issues/509.
In this change, the actual issue isn't fixed. It only adds the reproduction.
It uses the jasmine test runner, since it's already used by the docs test. That uses version 1 of Jasmine, which isn't ideal, but I want to be consistent for now.
I discussed with Tobias the possibility of switching to Mocha for these nodejs-based tests, and we might do that sometime later.
Export files are now directly under the module folder,
e.g. `core/core.js`. With this, an import like `core/core`
won’t need a path mapping (e.g. via `System.paths`) any more.
This adds the `src` folder to all other import statements as well.
modules/angular has no implementation, but depends on all the pieces
that make angular - core, di, directives, etc. It is the package that
all client apps will depend on.
- adds console and cloud reporter (via Google BigQuery).
- makes parameters of tests explicit and modifiable.
- removes `detect` and `ignoreGc` mode from benchpress
as these can result in unstable numbers.
Shows the metrics:
script, render, gcAmount, gcAmountInScript, gcTime
Run modes:
- detect: auto detect whether to force gc
- forceGc: forces a gc before every run and ignores no runs
- noGcInScript: ignore runs that have gc while a script was executing
- plain: does not force gc nor ignore runs
Closes#368
Major changes:
- make API more reusable
- format output nicely
- only force gc if needed
Regarding forcing gc:
Forcing gc can change script execution time.
We now don't force gc at first and ignore results where gc happens during script execution.
When we ignored too many results, we switch to forcing gc.
Closes#339
- use performance log of chromedriver / appium to get timeline data
for calculating metrics for benchmarks
- change all benchmarks to be made of a standalone application
and a protractor test that collectes timeline data
- fix and simplify benchmarks
- add dart2js to build
- remove benchpress
Closes#330
simplify:
- use same html file for dart and JS
- build benchmarks automatically when doing `gulp build`
- centralize configuration
modularize:
- move all build tasks into separate node.js modules under
`tools/build`.
changes:
- the `build` folder is now the `dist` folder
Closes#284
This used to be valid code:
```
class Foo {
constructor() {
this.bar = ‘string’;
}
}
```
This will now fail since ‘bar’ is not explicitly
defined as a field. We now have to write:
```
class Foo {
bar:string; // << REQUIRED
constructor() {
this.bar = ‘string’;
}
}
```
Supports:
- binds text nodes, element properties and directive properties
- locates decorator, component and template directives.
- inline templates of components
The compiler is built using a pipeline design,
see core/src/compiler/pipeline package.
Integration tests to show how the compiler, change_detection and DI work
together:
core/test/compiler/integration_spec.js
For Karma, the source mapa are inlined inside each source file.
For `build/*` output, separate `*.map` file is created.
This changes the API of `tools/transpiler/index.js`. I believe this API
is only used in `gulp-traceur.js` and `karma-traceur-preprocessor.js`.
Instead of returning the transpiled string, `compile()` returns a result
object such as:
```js
{
js: ‘transpiled code’,
sourceMap: null || {}
}
```
Closes#20
Alex Eagle
Martin Probst
Igor Minar
Rado Kirov
Tim Blasi
Rob Wormald
Pawel Kozlowski
Caitlin Potter
vsavkin
Patrice Chalin
gdi2290
Marc Laval
Jacob MacDonald
Tobias Bosch
Yegor Jbanov
Kevin Moore
Jeff Cross
Vojta Jina
Victor Berchet
Tommy Odom
Misko Hevery