`meteor run` doesn't always write changes to `.meteor/versions`: it only
does so if its release (or checkout-ness) matches `.meteor/release`. So
it preferred to just remember the value of `.meteor/versions` from
rebuild to rebuild rather than forgetting what it knew and re-reading
the possibly-not-updated file.
However, if some other process changes `.meteor/versions`, it would
ignore that change. With this fix, if `.meteor/versions` changes then
that is considered to be the previous versions list, not the last
version list from the same process. For example, this would commonly
happen due to using `meteor update` to update packages (without changing
the tool, which would cause the runner to stop).
Fixes#3582.
This restriction was originally in place because we did not know of a
use case for bare files on the server. The main use case for bare files
is putting pre-existing files in your app which expect top-level `var`s
to be "exported", which is common in browsers but not in Node.
However, there is a use case for this on the server: putting
pre-existing files that were originally written with clients in mind but
which function fine on the server into your server code. So we'll relax
the restriction.
Fixes#3681.
We're going to need to set other properties than `value` at some
point, and since `this.name` already holds the name of the property,
there's no reason for this class to be specific to "value"
attributes.
It was broken because fake-warehouse and test-package-server were
incompatible. In order to actually use the published packages, we had
to sync test-package-server into the local warehouse. But as soon as we
did that, the latest release became some other random release.
In any case, the semantics tested here have changed twice since 0.9.0!
In 0.9.0.1 we changed it from "ask for any RC means get any RC" to
"don't get any RCs that aren't explicitly anticipated". And in 1.1
we're changing it to "minimize unanticipated RCs".
Manually running through the equivalent of this test, most of it works
except for the last line; `meteor update` will not take you from one RC
to the next, due to minimizing unanticipated RCs. That's probably fine
though.
While we're at it, make it much more clear that warehouse and
test-package-server don't work together.
Adding the same file twice in the same package is now an
error. Previously, this could either lead to the file being included
multiple times (eg, JS), or to a build time crash (eg, client-side
assets).
Before:
While reading package from
`/private/tmp/meteor-duplicate-path-error/packages/dupe`:
/Users/glasser/.meteor/packages/meteor-tool/.1.0.45.1y6cwq8++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/tools/package-api.js:22:5:
Invalid 'where' argument: '[object Object]'
at Array.forEach (native)
at Function._.each._.forEach
(/Users/glasser/.meteor/packages/meteor-tool/.1.0.45.1y6cwq8++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/underscore/underscore.js:79:11)
at toArchArray
(/Users/glasser/.meteor/packages/meteor-tool/.1.0.45.1y6cwq8++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/tools/package-api.js:22:5)
at PackageAPI._.extend.addFiles
(/Users/glasser/.meteor/packages/meteor-tool/.1.0.45.1y6cwq8++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/tools/package-api.js:287:12)
at package.js:2:7
After:
While reading package from
`/private/tmp/meteor-duplicate-path-error/packages/dupe`:
package.js:2:7: Invalid 'where' argument: '[object Object]'
The major problem here was that numeric useMyCaller never quite worked,
since useMyCaller was only used to calculate the file/line/etc for the
error, and not to convince formatMessages to not print the rest of the
stack.
The other issue is that `_.each` adds two levels of stack over just
using a `for` loop, whereas 8bcbd6534 only added 1 to the useMyCaller
argument.
