2443d832 (in 1.0.4) ensures that the repl doesn't overwrite `_`, but it
replaces the server's global `_` with shell-server's `_`. This changes
appears to preserve it.
Fixes#4010.
This particular piece of code (introduced in #1407) would decide that
Plugin.registerSourceHandler('foo.bar') would match a file named
'foo.bar', but that was not the intention. In an app, the (correct) code
in getSourcesFunc does expect the leading period to exist, so you end up
with an odd situation where this code allows equal matches, but it only
gets to see the file if it's in a package (not app) or if there's
another plugin registering for 'bar'.
Fixes#3985.
Addressing: https://github.com/meteor/meteor/issues/3977
HttpHelpers.getUrl sometimes throws an error, and sometimes throws a string. The right
thing to do is to fix getUrl everywhere, but for now, let's get better error handling
in package-client.js
Velocity has visited the mirror sometimes before
it is ready. With this new check that is already
used in the testing frameworks this no longer
happens.
This commit also handles the upcoming breaking
change regarding the rootUrl of the mirror.
See: https://github.com/meteor-velocity/velocity/issues/260
Starting with cordova-lib 4.2.0 (shipped with Meteor 1.0.4) the cordova
create command checks that app IDs look like Java namespaces. Clean up
the most obvious ways that our generated app IDs won't look like Java
namespaces (most notably hyphens).
This isn't perfect (eg we don't check for leading digits or
consecutive/leading/trailing dots, or for Java reserved words). This
check is implemented by the valid-identifier NPM package.
While we're at it, put app ids under `com.meteor.userapps` so that there
are other parts of `com.meteor` available for potential MDG Java work.
Fixes#3950.
Starting with cordova-lib 4.2.0 (shipped with Meteor 1.0.4) the cordova
create command checks that app IDs look like Java namespaces. Clean up
the most obvious ways that our generated app IDs won't look like Java
namespaces (most notably hyphens).
This isn't perfect (eg we don't check for leading digits or
consecutive/leading/trailing dots, or for Java reserved words). This
check is implemented by the valid-identifier NPM package.
While we're at it, put app ids under `com.meteor.userapps` so that there
are other parts of `com.meteor` available for potential MDG Java work.
Fixes#3950.
When the tool runs the constraint solver to see what releases can
be chosen, it creates its own ProjectContext and does not pass
command-line flags through. Additionally, if the release you ask
for is not possible to choose for whatever reason (constraints in
.meteor/packages, and now the guard against downgrading root
dependencies), the error is swallowed and a pleasant "success"
message is printed. We should probably fix this at some point.
For now, `meteor update --release` just runs the constraint solver
as if `--allow-incompatible-update` was passed, which effectively
means it gets to ignore `.meteor/versions` if necessary.
There's no detail yet, but I'm going to add some. In the mean time,
you just get the total ms for "Selecting Package Versions...", and
if it runs a second time you'll get another report for "(Try 2)"!
It used to create a directory with an underscore instead of a colon
Now, it just removes the prefix.
In cases where the name of the package has more than one colon or starts or ends
witha colon, we report an error.
With this change, `meteor update` with no arguments, in addition to
updating direct dependencies, updates patch versions of indirect
dependencies, so you will get your version 1.4.2 in the above example.
Background: As of the new solver, we already prefer patched versions
when selecting a version for a new indirect dependency. For example,
if 1.4.0 is the oldest version we could choose, we will take 1.4.1
instead if available. However, if 1.4.2 came out, there would never
be an occasion to take it, unless you explicitly typed
`meteor update the-indirect-dependency`. `meteor update` with no
args expands to `meteor update <all direct deps>`.
Also improve comments, tests, and code around CS.Input.
It's been auto-failing for many months. If somebody wants to fix it,
feel free to revert this and fix it, but there's no reason to just
entirely stop self-test --slow from having any hope of passing forever.
The test is fine, but we were publishing a different version than we checked for.
(That is, we published 1.1.0, and were surprised when 1.0.1 did not show up).
Fixed.
It's been auto-failing for many months. If somebody wants to fix it,
feel free to revert this and fix it, but there's no reason to just
entirely stop self-test --slow from having any hope of passing forever.
Verified manually that `meteor update asdf.` displays an error,
not a stack trace.
Include the offending name in all error messages (as we do for
invalid versions).
Otherwise for some npm packages which output a lot during install, installation simply fails with no clear error message. node.js kills the process and there is no information about that in anything Meteor prints out: "maxBuffer specifies the largest amount of data allowed on stdout or stderr - if this value is exceeded then the child process is killed."
build, deploy, --prepare-app, and --get-ready for now.
Make the error message more generic (not mention which commands
support the flag, because it will be basically "all" of them). Also
replace "breaking" with "potentially incompatible" as discussed with
Matt a while back.
This reverts commit 4a6dd52bca.
This made some tests flaky because notSpaceSensitive sometimes (but not
always!) ate the newline after the regexp.
We should just disable word wrapping in processes run by self-test
instead.
This reverts commit 4a6dd52bca.
This made some tests flaky because notSpaceSensitive sometimes (but not
always!) ate the newline after the regexp.
We should just disable word wrapping in processes run by self-test
instead.
The test is fine, but we were publishing a different version than we checked for.
(That is, we published 1.1.0, and were surprised when 1.0.1 did not show up).
Fixed.
