It's a shame that Pathwatcher issues this warning using console.error,
without taking any verbosity options into account:
https://github.com/atom/node-pathwatcher/blob/7ef76e5dfd/src/main.coffee#L53
Fortunately, I believe I've identified the underlying reason why this
happens, which may help resolve the following issue:
https://github.com/atom/node-pathwatcher/issues/98
If all goes well, I'll submit an upstream pull request.
I've also reinstated an old file watching test that I mistakenly removed
when I attempted to switch to chokidar instead of pathwatcher.
This is a bit different from the previous strategy of invalidating
optimistic functions for specific npm package names.
Now, whenever we make changes to the contents of a specific node_modules
directory, or whenever the developer independently modifies an app's
node_modules directory, all optimistic results derived from paths
contained within that node_modules directory will be marked as dirty, and
thus may need to be recomputed.
This strategy prioritizes starting fewer watchers (just one per
node_modules directory) while still allowing npm packages to be added or
removed while the app is running:
https://github.com/meteor/meteor/pull/7668#issuecomment-255120373
The drawback is that changes within subdirectories of node_modules will
not be detected until the server is fully restarted, but that seems like
an acceptable tradeoff, since npm packages change much less often than
application code.
Most notably, this update provides error stack traces that include context
from Promise.await calls and await expressions, so (for example) you can
tell where a certain yielding files.* method was originally called,
instead of only getting a useless native stack trace.
Using a the previously-supported ability to pass a function (versus a string) for an oAuth1 URL, this commit implements (and relocates) a function which safely applies whitelisted params to that URL.
This introduces a twitter_common.js file shared between server and client which indicates which Twitter-supported params are permitted on the authorize step. The two params which Twitter supports right now are `force_login` and `screen_name`. (See: https://dev.twitter.com/oauth/reference/get/oauth/authenticate)
This commit removes the non-functional implementation of `force_login` introduced by meteor/meteor#6987 and implements it via the aforementioned method.
As a precaution (and since neither `ecmascript` nor `es5-shim` are used by this package), I stuck with JS ES3.
Closesmeteor/meteor#7584
While this seems like a good idea to find any edge-cases I wasn't thinking of, I'm afraid this would be be displayed frequently for users that set their `ulimit -n` higher in their shell profile since `ulimit -n` can only be lowered once explicitly set in a particular session.
This should permit watching as many files as the system permits. Previously, if the default ulimit was set to a value higher than 16384, it was lowered and if the user had configured their system to have a higher ulimit, Meteor wouldn't have take advantage of it.
Make the first attempt 32768 instead of 16384 since some users have large numbers of files or node_modules trees (meteor/meteor#6952). This hasn't been raised since Meteor started watching many more files nor since the addition of native NPM.
Previously, if the default ulimit was set to a value higher than 16384, it was lowering it. While this doesn't do much for users with default OS settings, those that have modified their ulimit settings will have their settings maintained.
This reverts commit b69716d778.
Now that we have a better system for invalidating optimistic results
derived from node_modules paths, these optimizations are safe (and yes
fourseven:scss rebuilds successfully).
This fixes a bug that prevents fourseven:scss from properly rebuilding,
because the new .../node_modules/node-sass/vendor/<platform>/binding.node
file is not found by Builder#copyDirectory, because the cached results of
optimisticReaddir are the same as before the rebuild.
Unfortunately, this change introduces a small performance regression
(hundreds of milliseconds at worst), because these files.* methods are
called many times.
I think we can continue using optimistic functions here if we are more
careful about invalidating their results, especially after calling
meteorNpm.rebuildIfNonPortable, but I'll save that for a future commit.
When a download aborts prematurely, the status code is often 200 OK, even
though we probably should not proceed with any further processing of the
downloaded information.
This silent failure leads to problems like the dreaded "Error: ENOENT: no
such file or directory, open... os.json" (#7806 and others), which were
hard to diagnose properly because the failure occurred only later, when
extracting a buffer that downloaded incompletely.
The getUrlWithResuming helper should be able to retry after this error is
thrown, which will result in a more helpful warning, even if in the most
common case, i.e. MaxCDN failure, it will never actually succeed.
Note that this change will not help until Meteor 1.4.2 is officially
released and becomes the implementation used to download later releases.
Mitigates #7806.
File#computeAssignedVariables is one of the most expensive methods called
during initial startup. This change significantly reduces the number of
times it needs to call through to findAssignedGlobals, which saves quite a
bit of parsing time. The exact savings are hard to quantify, of course,
because they depend entirely on how many modules you have in your app's
node_modules directory.
Scanning for global variable assignments is only really useful in Meteor
packages, where we sometimes need to intercept assignments for the
purposes of api.export, though this is increasingly unnecessary now that
you can (and should) just import values from node_modules.
In the app, the only possible value of intercepting global variable
assignments was to prevent polluting the global scope, but we don't even
create a private scope for the app when useGlobalNamespace is true, so
there really was no point to scanning app node_modules.
This is a refinement of my previous commit 56c041c858.
The Meteor babel-runtime package does not provide substitutes for
babel-runtime/core-js/* modules, so we should not be discarding them from
the client bundle.
Fixes#7930.
