Not currently supported in minimongo, so I'm not sure we want to
document it yet. Supporting it (and making it consistent) in MM
will take a little bit of work:
https://github.com/meteor/meteor/issues/1201
This reverts commit 9e6ebde836.
Now that the `dev_bundle` link is called `.meteor/local/dev_bundle`, and
`.meteor/local` is already ignored, we don't need to ignore
`.meteor/dev_bundle` anymore.
If a developer tried to `meteor update` a project whose `.meteor/release`
file corresponded to a version of `meteor-tool` that no longer exists in
`~/.meteor/packages/meteor-tool`, this code would throw an ENOENT error.
This could be fixed by running `meteor update --release <old release>`
first, but that kind of workaround shouldn't be necessary when updating
Meteor to the latest version.
This change should be mentioned as it those who were manually prefixing their relative CSS paths with the same path as their ROOT_URL will need to remove the path.
Relates to meteor/meteor#7416
Fixes regression caused in 1.3.4.1 which caused network path reference URLs (i.e. //img.domain.com/path/font.eot) used in CSS `url()`'s' to be stripped of their leading slashes causing them to become relative URL paths.
Closesmeteor/meteor#7416
As a refinement of my previous commit, we will continue setting the
$GYP_MSVS_VERSION variable to "2015" except in cases where the Python
library behind node-gyp succeeds in inferring the correct version.
Note that the Python library will never infer "2015" by itself, even
though that's the version recommended by the node-gyp setup instructions:
https://github.com/nodejs/node-gyp#installation.
Note also that the Windows machines used by `meteor admin get-machine` and
build.meteor.com have version "2010e", which can be inferred.
In other words, this commit allows the following groups of developers to
avoid setting $GYP_MSVS_VERSION manually:
1. Developers who followed the node-gyp setup instructions.
2. Package authors who run `meteor publish-for-arch` on build machines.
Setting GYP_MSVS_VERSION to 2015 when the Visual C++ 2015 build tools are
not (and/or cannot be) installed is (in my experience) the leading cause
of `npm rebuild` failures on older Windows machines.
Auto-detecting the appropriate version is something node-gyp ought to be
able to do as well as Meteor possibly could, at least according to
https://github.com/nodejs/node-gyp/blob/1dcf356ca7/gyp/pylib/gyp/MSVSVersion.py#L222-L223
When selecting a different version is important, you can always set the
GYP_MSVS_VERSION environment variable yourself. Specifically, if you're a
package author, and your package depends on npm packages that can only be
compiled with a newer version of MSBuild.exe, then you might need to run
$env:GYP_MSVS_VERSION = "2015"
meteor publish-for-arch name:package@x.y.z
I fully trust that the folks in that small category can handle that
additional burden.
We now use a smaller file (the `babel-compiler` archive instead of
`meteor-tool`), and we interrupt every 500kB, which leads to three total
interruptions for that file. Also, we only delay one second (instead of
five) between attempts.
This is a test that really needs to run and pass every time we run the
test suite, so I decided it shouldn't be --slow. If it takes too long, we
can always download a smaller test file.
Hard-coding the download length was a recipe for brittleness, so now I'm
downloading the file without interruptions in parallel with the
interrupted/resumed download, so that we can compare the two files when
both have finished downloading.
Follow-up to #7399.
