Originally we destroyed the oldValue by incrementaly copying over portions of the newValue
into the oldValue during dirty-checking, this resulted in oldValue to be equal to newValue
by the time we called the watchCollection listener.
The fix creates a copy of the newValue each time a change is detected and then uses that
copy *the next time* a change is detected.
To make `$watchCollection` behave the same way as `$watch`, during the first iteration
the listener is called with newValue and oldValue being identical.
Since many of the corner-cases are already covered by existing tests, I refactored the
test logging to include oldValue and made the tests more readable.
Closes#2621Closes#5661Closes#5688Closes#6736
`log.empty()` is the same as `log.reset()`, except thati `empty()` also returns the current array with messages
instead of:
```
// do work
expect(log).toEqual(['bar']);
log.reset();
```
do:
```
// do work
expect(log.empty()).toEqual(['bar']);
```
from our experiements it appears that the presense or absense of the from and resolved properties
makes no difference on the behavior of but updates these properties
with different values depending on different state of the cache and node_modules.
So in order to get clean diffs during updates, we are just going to drop these properties and have
a script to do this automatically.
Long term this should be fixed in npm: https://github.com/npm/npm/issues/3581
PR #5547 introduced conversion of all 0 status codes to 404 for cases
where no response was recieved (previously this was done for the
file:// protocol only). But this mechanism is too eager and
masks legitimate cases where status 0 should be returned. This commits
reverts to the previous mechanism of handling 0 status code for the
file:// protocol (converting 0 to 404) while retaining the returned
status code 0 for all the protocols other than file://
Fixes#6074Fixes#6155
The recent $$RAFProvider which is a wrapper for the native
requestAnimationFrame method doesn't use the mozRequestAnimationFrame.
Old versions of FF (20 for example) crash if ngAnimate is included
No breaking changes and fix issue https://github.com/angular/angular.js/issues/6535Closes#6535Closes#6540
We need to be able to build angular at older shas, without the lock file / shrinkwrap file
the dependencies will resolve differently on different machines and at different times.
This will help us avoid broken builds and hard to track down issues.
I had to manually edit this file after it was generated because `npm shrinkwrap` will install
optional dependencies as if they were hard dependencies.
See: https://github.com/npm/npm/issues/2679#issuecomment-37361236
My manual edit:
```
diff --git a/npm-shrinkwrap.json b/npm-shrinkwrap.json
index 756df44..dc157eb 100644
--- a/npm-shrinkwrap.json
+++ b/npm-shrinkwrap.json
@@ -3110,19 +3110,7 @@
"chokidar": {
"version": "0.8.1",
"from": "https://registry.npmjs.org/chokidar/-/chokidar-0.8.1.tgz",
- "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-0.8.1.tgz",
- "dependencies": {
- "fsevents": {
- "version": "0.1.6",
- "from": "fsevents@0.1.6",
- "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-0.1.6.tgz"
- },
- "recursive-readdir": {
- "version": "0.0.2",
- "from": "recursive-readdir@0.0.2",
- "resolved": "https://registry.npmjs.org/recursive-readdir/-/recursive-readdir-0.0.2.tgz"
- }
- }
+ "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-0.8.1.tgz"
},
"glob": {
"version": "3.2.9",
```
Additionally chokidar doesn't list the dependencies above as optional, but that will hopefully
be soon fixed: https://github.com/paulmillr/chokidar/pull/106
In the meantime the patch from the PR above needs to be applied to
node_modules/karma/node_modules/chokidar/package.json before running `npm shrinkwrap`
----
After this change is applied, angular core developers don't need to do anything differently,
except when updating dependencies we need to call `npm update && npm shrinkwrap --dev`
followed by reappling my patch above until npm's bug.
Closes#6653
for an unknown reason the VMs can't connect to local karma, so all builds on Jenkins (ci.angularjs.org)
are failing right now.
Since we want to kill Jenkins anyway, and travis tests on IE, this should not have any
significant impact on us.
Conflicts:
jenkins_build.sh
The docs were relying on the grunt/util module for getting version info
but this was unreliable and full of custom regexes. This is moved into
a new version-info module that makes much better use of the semver library.
