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
fixes#11 (constructor and typed field semantics)
fixes#42 (Should we infer class property types from ctor args ?)
fixes#17 (number (js) should map to num (dart))
Closes#45
`pub get` is now only executed when the `pubspec.yaml` in the `modules`
folder is different than the `pubspec.yaml` in the `build/dart` folder.
Generates the file `build/dart/_analyzer.dart` that imports all modules
to run `dart analyzer` against all of them. The build will fail whenever
there are errors, warnings or hints in `dart analyzer`.
Changes the sources so that `dart analyzer` does not report any
error, warning or hint.
Closes#40
* remove `wraps` syntax enhancements for imports
and support new `import * as module from ...` syntax
- default imports are the wrong construct for importing
everything from a module
* moved tests from transpiler to jasmine and karma
- transpiler tests are included when running karma in main project folder
- transpiler is reloaded after every test run in karma,
so no need to restart karma when the transpiler has been changed.
- removed own gulp build for transpiler and `postinstall.sh`
as they are no more needed.
- transpiler tests are now executed in Dart AND JavaScript (used to be executed
only in Dart), which allowed to catch some bugs (see the bug with the
import specification above).
* made tests work in dart as well by using the following hack:
- dependencies are loaded from the `build` folder, which makes
running `gulp build` necessary before running karma for dart
- for this to work,
the dependencies are included in main `pubspec.yaml` of project
- reason for the hack: `karma-dart` loads all `packages` urls
directly from disc (should rather use the karma file list)
* added explicit annotations `FIELD`, `ABSTRACT`, ... to `facade/lang.*`
- needed for now that we can run tests and don't get errors for undefined
annotations.
* added `README.md` with details about the build and tests
Note: karma with dart is still not working
because of how `karma-dart` loads `package:…` dependencies.
Usage:
```
karma start karma-js.conf.js
karma start karma-dart.conf.js
```
Make sure to set `DARTIUM_BIN` env variable.
Refactors `js2dart`:
- live outside of the traceur module (`tools/js2dart/index.js`)
so it can be reused by gulp and karma
- automatically build the sources in memory,
so that `js2dart` can be used without running `gulp build` first
- provide a way to specify the moduleName of a compilation run
independently of the input filename. This helps error messages
and source maps (not yet enabled) to report the correct file name
Changes project setup:
- add module `test_lib` that contains the primitives for tests
(e.g. `describe`, `it`, …)
- clean up some sources that had errors in them
- module names in transpiled js and dart files don’t contain
`lib`, `test` nor `src` any more (e.g. `di/di`).
When chaining a `pubspec.yaml` we automatically run `pub get`.
In `gulp build` we also run `dartanalyzer` for all files
that have the pattern:
`<module>/lib/<module>.dart`
Closes#13Closes#5Closes#2
Rado Kirov
Marc Laval
Tobias Bosch
Jeff Cross
Vojta Jina
Victor Berchet
vsavkin
Tommy Odom
Misko Hevery
Chirayu Krishnappa