This will be a simple follow-up release to Meteor 1.5.2, with the most important inclusion being Node v4.8.5 which includes a Node.js security update as explained in the v4.8.5 release blog. Due to the timing of the Node.js security release, the fixes for our garbage collection patch, which fixed a recurring segmentation fault which manifested itself during Meteor development, were pushed to Node v4.8.6 (which will likely be the last v4 Node.js release). Therefore, this version of Meteor will still ship a version of Node which includes our fix until we can move back to the official v4.8.x releases.
A change to the import scanner is also being included to address the problem in #9182, which was fixed by #9187 and some follow-up commits. As well as a change which should reduce the size of the
For Unix platforms, the first release candidate is already ready to test. Please try it as soon as possible and report any issues here!
Unfortunately, I ran into a bit of an issue publishing the Windows version of that build, and I'll have to finish looking into it next week.
While the actual version included for Unix developers will be our own build at NODE_VERSION, this is important for the Windows version, since it is not being rebuilt by our Jenkins at the moment.
By checking and setting this property earlier, we can avoid scanning files more than once.
Previously, if more than one module in a package tried and failed to import the same identifier, we would record information about only the last failed import. This was good enough for later attempting to resolve the failed import in other packges or the application's `node_modules` directory (a concept known as "peer dependencies"), but it sometimes discarded information about whether the failed imports were dynamic. In particular, if the last recorded failed import was a dynamic import, it could accidentally render the entire peer dependency tree dynamic. Although it's a bit more complicated than what we did before, I believe the simplest solution is for the ImportScanner to maintain a mapping from failed identifiers to lists of import information objects, rather than a single object, so that no information is lost.
The `installPath` property was always essentially an absolute module identifier that was simply missing the leading '/' character, so this commit acknowledges that role by renaming the property to `absModuleId` and adding the leading slash.
i've experienced segmentation faults when running in production, ie running the bundle with "node main.js" (i'm using mup with abrenix:meteord)
This reverts commit b9f0a54. Though probably a good idea for the future, this change was not really necessary for Meteor 1.6, and probably too risky for a release candidate.
These errors are especially harmful because they cause files.rename to fall back to copying rather than atomically renaming, which is both much slower and not even remotely atomic.
This should hopefully prevent ENOTEMPTY errors on Windows.
A while back, for performance reasons, we disabled yielding for all files.* operations unless METEOR_DISABLE_FS_FIBERS was set to false. This was safe for almost all files.* operations, because most of them have a synchronous fs.*Sync version available. For a more complicated operation like files.rm_recursive, however, there is no synchronous or asynchronous counterpart in the fs.* namespace, so the safety of disabling fibers is not guaranteed. Lately, files.rm_recursive has become a major source of uncaught ENOTEMPTY errors on Windows, because rimraf.sync fails with that error, and we don't give files.rm_recursive_async a chance to delete the directory in a more persistent, forgiving manner. The only reason we haven't been falling back to files.rm_recursive_async is that YIELD_ALLOWED is false by default, so canYield() returns false. This commit distinguishes between canYield() and mayYield(), and uses canYield() in files.rm_recursive to determine whether it is technically safe to yield, regardless of YIELD_ALLOWED. Anyone who ever asked "Can I go to the bathroom?" in elementary school, only to be mercilessly rebuked with "I don't know, CAN YOU?" should understand the difference between these two functions.
This was dangerous because source is often a path relative to the old target file, whereas files.stat was interpreting source as a path relative to process.cwd(). Fixes #9203.
Commit 86ec7eb broke tests because we rely on symlinks even when the symlink option is false.
Good shout on reverting 4e778b6, @benjamn. In fact, that turned out to be the solution to the Windows publishing problem. I opted to just revert that single commit and not rebase since I had already published
Meteor 1.5.3-rc.1 is now published for all its supported platforms (specifically: keep in mind that there will only be a 32-bit Windows build, whereas Meteor 1.6 is now available on Windows in a 64-bit flavor as well).
This implements a first generation of Windows CI testing. Presently, this only runs valuable, hand-picked tests which have been known to work in the past, and whose failure would indicate a critical problem. A test which isn't passing doesn't mean that the feature being tested is not working. For example, the 'create' test fails ostentatiously, though the 'meteor create' command certainly works in practice. This points to problems some compatibility problems with the 'self-test' harness itself, some of which I'm aware of. Though, it likely will highlight some legitimate problems which Windows users experience too. There are a number of additional tests which should be enabled which likely pass already, and many more which are failing and we should fix. Additional tests can be added to the scripts/windows/appveyor/test.ps1 file as they've been deemed working. Altogether, this will take extensive work to achieve the same level of coverage our Unix test suite enjoy, but we've got to start somewhere! cc @benjamn
These take precedence over the UI, and I'm not sure the UI is taking effect at the moment. We don't need to build branches which start with 'dev-bundle-' since those dev bundles won't be built yet when the tests are kicked off.
Though it was thought to be reliable when running through 'self-test' on Windows, it's yet to be seen how reliable. The worst thing that could come of adding Windows testing would be that we have test failures again after such a string of green checkmarks and confidence. Also, reordered.
Even with $ErrorActionPreference, PowerShell won't automatically fail when an external command fails with an error code. This explicitly checks those exit codes and throws an error when that occurs. Hopefully prevents false successes like that shown in this AppVeyor test run: https://goo.gl/xxRsF9.
Note that since Meteor 1.6 is the most recent, it will be necessary to use the