Revert "Bump webapp version to 1.8.2, with same content as 1.8.0."
This reverts commit 20d2a9b4a4.
Revert "Revert changes to webapp package since version 1.8.0."
This reverts commit 7a6ee9e129.
We accidentally published changes to webapp that should have been
restricted to Meteor 1.10 as part of the 1.8.1 version. This commit
reverts commits to packages/webapp since Meteor 1.9, so that we can
republish the 1.8.0 content as version 1.8.2. We will then bump the webapp
version to 1.9.0 on the release-1.10 branch and publish the new content
only on that branch.
Revert "Allow to exclude web architectures in development mode (#10824)"
This reverts commit a205967186.
Revert "Updates cordova-plugin-meteor-webapp to 1.7.1"
This reverts commit a1e4d27822.
Revert "Update cordova-plugin-wkwebview-engine to 1.2.1."
This reverts commit 3f9a69d7c4.
Revert "Update cordova-plugin-whitelist to 1.3.4."
This reverts commit 979273333b.
Revert "Update cordova-plugin-meteor-webapp to 1.7.1-beta.1."
This reverts commit 565c4254f1.
Revert "Update accounts-password to version 1.5.2."
This reverts commit b827d1da2f.
- This changes meteor deploy to poll the /version-status/ REST endpoint
in Galaxy for the build and deploy status of the returned version
- Also fixes up a typo in a test
- Currently only configured to use a default polling configuration
- This change also adds a flag called --no-wait which allows users to
specify that they want the deploy command to behave just as before
The `meteor build --architecture` help was missing
`os.windows.x86_64`. This commit adds it in and also updates
an out of date comment in the source that referred to there
only being 3 allowed architectures.
As explained in the entry for the `meteor` command, the first line of each
entry in help.txt is the summary for autogenerated command lists, and thus
will not be displayed in the help for the command.
* Adjust test filename RegExps to match Meteor guide. Fixes#9332.
* Adjusted help text for --drive-package on meteor test.
* Add integration tests for `meteor test` eager file loading.
* Fix typo in selftest.forbid comment.
* Improve test file eager load integration test coverage and clarity.
It's still possible to publish packages for different platforms by using
the `meteor publish-for-arch` command, though it's become increasingly
difficult to offer compatible versions for every circumstance due to the
wide matrix of Node.js ABI versions. This makes it unlikely that
a package built on the build farm will be appropriate for the
application which the package is consumed by, substantially reducing the
overall value of rather expensive infrastructure.
Since Meteor 1.4, and as part of the jump from Node 0.10 to Node 4,
Meteor introduced the capability to compile binary dependencies at the
time that a package is installed. Additionally, many Node.js packages
are already pre-compiled in a much more effective and wide-spread nature
for the entire JavaScript ecosystem using tools like `node-pre-gyp`.
cc @benjamn.
The syntax of these flags is the same as the equivalent Node.js options:
https://nodejs.org/en/docs/inspector/#command-line-options
When no port value is provided, the default is 9229.
Two notable differences:
* The flags affect the server process spawned by the parent build
process, rather than affecting the build process itself.
* The --inspect-brk flag causes the server process to pause just after
server code has loaded but before it begins to execute. This timing is
more useful than the Node.js --inspect-brk behavior, which is to pause
on the first instruction executed by the process, since that is too
early to set any useful breakpoints.
Implements https://github.com/meteor/meteor-feature-requests/issues/194.
This is the feature that excites me most about Meteor 1.6, hands down.
Benefits include:
* Works with `meteor test[-packages] --debug-port 9229` (for tests), as
well as just `meteor debug` (for apps).
* The application process waits patiently for the debugger to attach, so
you don't have to race to open the debugger.
* The application process pauses at a location just after all server code
has been evaluated, but before any code starts executing, giving you a
chance to set reliable breakpoints anywhere in server code. This is much
better than using the `node --inspect-brk` flag, since that stops too
soon to set any useful breakpoints.
* The application server runs at full speed, so you don't have to wait
forever to hit that all-important breakpoint, and you don't lose nearly
as much time if you accidentally continue past the line of code where
the trouble is occurring.
* Even if your application is stuck in an infinite loop, you can still
attach the debugger, pause execution, and debug the loop.
* No more `node-inspector`! Instead, you can now debug your server code in
native Chrome DevTools, or several other high-quality inspector clients,
such as VS Code or WebStorm (seriously, check out the documentation:
https://nodejs.org/en/docs/inspector/#inspector-tools-clients). The list
of debuggable processes can be found at the URL chrome://inspect.
* Realistic performance and memory profiling is now possible via the
familiar DevTools interface.
* I highly recommend this Chrome extension that automatically (re)connects
to any open inspector sockets, so you don't have to keep manually
(re)attaching the debugger: http://june07.com/nim
* The implementation of `meteor debug` no longer has to proxy multiple
private/public debugger ports. Look at all that deleted code!
This new inspector is so much better than the old `node-inspector` that
I've been using the release-1.6 branch to debug problems in Meteor 1.5,
despite the risks of using Node 8, because those risks are so far
outweighed by the quality of the new debugging experience.
That said, the experience isn't perfect (yet). I welcome your feedback on
the Meteor 1.6 PR: https://github.com/meteor/meteor/pull/8728
* Update help text to clarify the use of external npm commands
First attempt to improve the help text regarding the external npm commands that can be run directly with 'meteor'.
#8277
Further enhancements could include listing also the "current" available external commands by parsing a ls/dir command or 'meteor npm list -g -depth 0'. If they command is uninstalled between the call of 'meteor help' and 'meteor <external command>' we are not the ones to be blamed but the user instead :)
* Update 'external command' to 'npm command'
* Joining new suggestions and cleaning some redundancy
Included @abernix suggestions (with some variations) to include references to npm and node. Also clarified how to install a npm package and run it afterwards
* Typo
Changed to global context
* Reword description of "other" npm commands
These commands are similar to `node` and `npm`, but we didn't want
them to be confused with `npm command` commands.
* Avoid repetition of `meteor npm install --global`
