The fix is actually in https://github.com/npm/fstream/pull/42,
but now we also remove our explicit path length check
that used to throw an error instead of silently losing files.
This commit also adds a self-test to test the entire flow
through `files.createTarball` and `files.extractTarGz`.
Fixes the bug where the history would be parsed as one big blob on Windows,
because it is always written with "\n" but parsed with "\r\n" on Windows and
"\n" on Unixy platforms.
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.
