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.
The jscript transform is perfectly safe for server code, and relatively
cheap compared to the cost of having to compile every file for both the
client and the server, just because the set of plugins is different.
meteor/meteor#7821 is a breaking change for anyone running the `meteor` tool as `root` right now. This moves it higher and explain that it's not just a warning.
If a test process does not explicitly call process.exit, pathwatcher
watchers may keep it alive indefinitely (either that, or there's a bug
with the persistent:false option to fs.watchFile).
This accidental immortality can be prevented by explicitly closing all
watchers when we no longer have any interest in file change notifications.
This is a refactor/finishing-move of @c9s's original PR meteor/meteor#7586.
This maintains backward compatibility with PACKAGE_DIRS using the original separator that it expected (':'). Users of the new METEOR_PACKAGE_DIRS variable should use the correct path separator for their platform (`:` on BSD/Linux and `;` on Windows).
Fixesmeteor/meteor#7585Fixesmeteor/meteor#4204
In particular, optimisticReaddir was getting called before relevant dirty
callbacks were firing, and thus failing to notice actual changes on the
file system.
In general, the tools/fs/watch.js code is the one place where we really
need an up-to-date view of the file system. Put another way, if optimistic
functions worked perfectly, we wouldn't need to rely so much on WatchSet
logic, but for now it's a balance of equally important strategies, and we
shouldn't be compromising one by intermingling it with the other.
This will make it easier to use tools like https://yarnpkg.com/ with the
right version of Node, etc.
With this commit, here's all you have to do:
meteor npm install -g yarnpkg
Then test that it works:
meteor yarn info
Note that any commands registered by Meteor itself will not be honored.
This is a wrapup/cleanup on @lucfranken's PR to clarify and clean up the "Slow Start (for developers)" section of the README.
The next step will be to move this to a separate file where much more information can be added, but this incorporates most of the original suggestions and adds some additional formatting.
The README explained how to run Meteor from a checkout.
The example used is the Meteor docs app which is available in the
Meteor repository itself. However it did not mention how you can run
the local Meteor checkout from a local app.
That is the most basic use case, for example to reproduce a bug. That’s
why an example of that is added based on meteor create so we focus on
creating a clean reproduction. That way we can point to it when people
want to debug their own issue.
This partially reverts commit 96c95629eb.
When running `meteor update`, we call writeReleaseFileAndDevBundleLink
immediately before reading .meteor/release, so there's no time for a file
change notification to invalidate the cached contents of that file.
In the future, we could perhaps call optimisticReadFile.dirty(path) as a
consequence of files.writeFile(path, ...), but that may be tricky.
Judging from the variety and extent of test failures, switching to
chokidar.watch was too drastic a change for this late-beta stage of the
release cycle.
The problem with pathwatcher.watch was that watches don't survive the
deletion of the watched file, because (like fs.watch) it watches files
based on inodes, not paths. This problem can be solved in a relatively
narrow way, by attempting to rewatch the file after any "delete" or
"rename" events.
Especially on Linux, chokidar.watch tends to throw ENOSPC errors when too
many files are being watched.
I removed this logic earlier because I thought chokidar could handle such
failures by itself, but that was wishful thinking.
