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
This may not be a complete fix for issue #8775, but I noticed while
debugging the issue that LocalCollection._removeDollarOperators isn't
removing nested $operators (as it seems like it should be):
d6c4281eeb/packages/minimongo/minimongo.js (L790)
cc @hwillson
This may not be a complete fix for issue #8775, but I noticed while
debugging the issue that LocalCollection._removeDollarOperators isn't
removing nested $operators (as it seems like it should be):
d6c4281eeb/packages/minimongo/minimongo.js (L790)
cc @hwillson
While this was helpful in one of the incarnations of the
bundle-visualizer during development it isn't relevant anymore since
the `.stats.json` will not be present in the bundle unless it was
created by a recent version of `standard-minifier-js` which passed
in `stats` (no older versions did this).
Removing this check will also make it possible for other minifiers to be
used with `bundle-visualizer` without them also needing to fork make
their own version.
This reverts commit c3b3550471.
Node 8 seems to do a better job than Node 6 of not crashing when memory is
running low, and asking for 8192MB caused an immediate segfault on our
Linux 32-bit build machines.
There have been a number of commits in the history for `rimraf` which
indicate others have also been struggling with ENOTEMPTY, specifically
on Windows.
https://github.com/isaacs/rimraf/commits/master
This commit, included in 2.6.1 takes a relatively aggressive approach:
d53235de86
However, due to the way the Windows filesystem is designed, this
approach may be the only way of coping with file-handles which are
cached by the OS and not released immediately upon closing a file
(in other words, at a time that Meteor would think it'd be safe to
remove the file/directory).
Attempts to help with meteor/meteor#8485.
This actually changed ages ago, in Node.js 0.11 via
fd3657610e
however the descriptive error message, which was previously
enabled with `true` as the third argument, was silently lost.
This reimplements the descriptive error message as mentioned in
https://github.com/meteor/meteor/issues/3200#issuecomment-289685677 by
@d-schiffner.
