@GeoffreyBooth and I are still deciding exactly what to do with the
coffeescript package in #8960, but in the meantime I need to publish
another 1.6 beta, and I'd like to avoid publishing a beta version of
coffeescript along with it.
Declaring a package-local variable called `process` in the `modules`
package causes uglify-js not to replace `process.env.NODE_ENV` with a
string literal value in any `node_modules` contained by the `modules`
package, which causes React Dev Tools to display a warning.
This Meteor package version does not need to track the npm version of the
coffeescript package, and probably should not change as often as the
version of the packages/non-core/coffeescript-compiler package.
They depend on core packages like caching-compiler, but coffeescript-compiler
can remain in non-core, so it can update more frequently as npm coffeescript
gets updated.
This fixes a problem reported by @arggh:
https://github.com/meteor/meteor/pull/8913#issuecomment-322048927
The problem appears to have been introduced by this commit:
2c5094fa0c
The reason this commit was problematic is that it turned several
Object.keys/forEach loops into for-in loops, which caused a few unchanged
return statements to take on a new meaning: instead of "continuing" the
loop by returning from the forEach callback function, the return
statements now returned from the enclosing function:
2c5094fa0c (commitcomment-23638205)2c5094fa0c (commitcomment-23638216)
Besides this refactoring hazard, what else is wrong with for-in loops?
First, for-in loops iterate over not only own but also inherited keys,
which makes them not exactly equivalent to Object.keys/forEach, which
iterates over only own keys. Another way to address that problem is to
initialize this.queries to Object.create(null) instead of {} (which I've
also done in this commit), so that there is no prototype chain.
Second, for-in loops are a trigger for deoptimization in V8:
https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#5-for-in
Since 2c5094fa0c was supposed to be about
improving performance, and these changes introduced some logical problems
as well, I think it's best that we avoid for-in loops.
This reverts commit 4d37a05fb3.
After git bisecting between origin/release-1.5 and origin/release-1.5.2, I
identified this commit as the culprit in recent failures of the modules
test app: https://circleci.com/gh/meteor/meteor/4857#tests/containers/3
Note that the modules test app seems to be failing only on Linux, and it
does pass reliably with this commit reverted. It must have something to do
with Mongo failing to start, and thus the "App running at" message never
appears, but I don't have a good theory why that might be.
The command to run just the modules test app is
meteor self-test --history 1000 'modules - test app'
@zimme @hwillson @abernix any ideas?
