This package is almost unnecessary now, though I suspect more polyfills
will be added in the future, so we might as well keep it.
Since we're loading so many fewer core-js modules, this change saves about
50ms of server startup time. That might not seem like much, but it's a
measurable savings that benefits every save-rebuild-restart-reload cycle.
Bug fixed: we should never be calling meteorDebugFuture.wait() in
production, so we now use process.env.METEOR_INSPECT_BRK in developement
to enable the waiting.
Lesson learned: if you call Fiber.yield() in the only running Fiber
without any other events scheduled on the event loop, the program will
immediately exit with code 0, as it should.
Closes#8817.
As discussed in https://github.com/meteor/meteor/pull/8777 it seems best
to always have the suffix on npm-wrapper packages.
If anything, as a reminder when bumping the version on wrapper packages,
but also just to generally make it more clear if a version suffixed with
`_1` is actually higher than a non-suffixed version or not.
* Fix documentation on MAIL_URL value
See https://github.com/meteor/meteor/issues/8804
* Fix long-lines for History.md.
This file is kept word-wrapped. :)
* Additional clarification.
E-mail protocols are far too confusing.
I will squash this commit.
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
* Bind environment of observeChanges callbacks
This will also bind observe callbacks
* Test bound environment in observeChanges
* Use named exception handler in bindEnvironment
If an observe/observeChanges callback throws and error this will make it a bit easier to figure out where the error came form.
* Update History.md
Being a bit more specific always helps.
