Since the beta versions of these packages are likely to overlap with
previously published beta versions on the release-1.6 branch, we should be
sure to use a distinct suffix like -beta152.n.
The pull request corresponding to our fork is not going to be merged, so
it's better to use the alternative this.finished API available in newer
versions of the upstream package.
https://github.com/williamkapke/node-eachline/pull/4
With Meteor 1.6 / Node 8, I noticed _buildLocalPackages taking multiple
seconds on initial server startup and restart, and the problem seems to be
that we call the global.gc function too often. This wasn't a problem in
previous versions of Node, as far as I know, but it makes sense to heed
the comment in tools/utils/gc.js, now that it matters.
When the babel-compiler package is updated, it appears that sometimes the
ecmascript package must also be updated, since it registers the compiler
plugin that uses babel-compiler.
After verifying that you're using both babel-compiler@6.19.4 and
ecmascript@0.8.2, you should probably run `meteor reset` just to be sure
you aren't still using any cached source maps.
IE11 doesn't handle properly attempts to change methods of the
window.localStorage, attempts to do so will result in the complete break of the
localStorage system for the domain in which it is done - until the user clean
the browser/domain cache.
Therefore, in the web, we don't set Meteor._localStorage to be a reference to
window.localStorage . Instead, we set proxy methods.
This will allow package developers that will find a need to change the behavior
of Meteor._localStorage methods to do so without breaking the localStorage
system on IE11. (e.g. meteorhacks:fast-render)
IE11 (earlier IE versions weren't checked) doesn't handle attempts to replace
methods of window.localStorage with different functions properly. Such attempt
will result in the String of the function we try to set saved as the function,
destroying the ability to use this function.
I couldn't find a way to tell in advance whether an attempt to set
window.localStorage will result in correct function write or not (I
intentionally avoid browser version detection, which is considered a bad
practice). If such attempt will fail we won't have a way to restore the
original function.
The situation is even worse than that. If for exapmle we'll try to set
window.localStorage.setItem = function () {} the String value 'function () {}'
will be saved instead of the function - not only for the current session, but
as part of the localStorage (!) meaning that we'll have to ask users affected
by this bug to clear the cache to fix the situation.
The following won't work:
```javascript
Meteor._localStorage = window.localStorage // Just to make example clear.
originalSetItem = Meteor._localStorage.setItem
Meteor._localStorage.setItem = function () {}
Meteor._localStorage.setItem = originalSetItem
typeof Meteor._localStorage.setItem -> string
```
