This will be useful when we want to be smart with windows file paths later
Also, all of the file calls are asynchronous with fibers now, which comes with
many benefits.
This is a combination of 23 commits. Original messages:
Wrap a large number of fs calls inside files.*
Convert a few more fs calls to files.*
More moving fs.* to files
Implement read/write streams and open/read/close
Get rid of fs from auth.js
Remove fs and unused imports from catalog-local and catalog-remote
Remove unused imports from catalog.js
Replace a whole lot of fs calls
Fix error
Migrate a lot more fs. calls to files.
Add a temporary symlink method
Convert old test to files.*
Use files.pathX instead of path.x everywhere
Replace path.x to files.pathX in tests
Small fixes to files.js and one rename
Make cleanup run in a fiber
Make wrapping functions take function name in case we need it
Add some timeouts and stuff to HCP tests
wrapFsFunc also makes a sync version of the function
Sometimes you just don't want to yield!
Make sure JsImage readFromDisk doesn't yield
Remove unused imports from npm test
Change order of test now that some things don't yield
Fix missing files import, and add a debug error printout
For freshly created apps, this commit reduces the time required to start
the development server from 4.6s to 2.5s on my machine.
Not calling findMongoAndKillItDead unless Mongo fails to start shaves off
a few hundred milliseconds, too.
Fixes#3010.
You can only request a named set of packages, not a random assortment.
In future commits, we will pre-build these packages into JsImages and
load them from that. Building packages for uniload will eventually not
involve the .build.foo directories at all. (All saved packages will be
built in app context, eventually.)
Port a simplified version of Meteor.EnvironmentVariable and
Meteor.bindEnvironment to fiber-helpers.js to deal with this.
Identify uses of fiberHelpers.inFiber and switch them to either
fiberHelpers.bindEnvironment (if the callback they are wrapping is
semantically "part of" the context that creates the callback) or
fiberHelpers.inBareFiber (otherwise).
Without this, concurrency was causing the wrong buildmessage message
sets and jobs to be active when builds yielded.
springboarding happens infinitely because of build ids
have to manually bootstrap a tropohouse
fixed some other things:
- store package server token in correct domain
- copy files (eg packages pre-publish) with +x flags
- catalog.getReleaseTrack works
- don't pass release to uniload (Meteor.release will always
end up 'UNILOAD')
- fix building meteor-tool again
- stop supporting apps without .meteor/release
- merging unipackages with tools works
springboarding to warehouse releases totally not supported
This is only intended for testing. No data is preserved from one run to
the next, and if any mongod exits for any reason, the rest are killed;
there is no mongod restarting.
It takes a while (~20 seconds) to start up because it waits for the
replset to be ready.
Before this, if the runner decided to stop (eg, because mongod is
crashing too much) while waiting for file change, it would crash due to
an attempt to wait within a fiber. Fixing that bug by adding an inFiber
would then lead to the process just not exiting, because nothing stops
the wait-specific future.
If you happen to introduce a circular require into the stack, this
object will be undefined.
Instead, hang on to `require('./run-log.js')`, which is the exports
module which does get filled in later.
The rationale: RunLog is an object that is hardcoded around managing two
other singletons: stdout and stderr. Having multiple RunLogs wouldn't
work well without improving RunLog to have the ability to control other
streams.
We'd like to be able to use RunLog from other places in the tool, most
notably from code called from bundler (while running an app) such as the
npm updater. But threading a RunLog object through that code is
difficult (especially as bundling takes a detour through
release.current.library).
Could cause mongo startup to hang.
Reproduction:
$ meteor
=> Meteor server running on: http://localhost:3000/
# ... wait for server to start, ctrl-c.
# leaves '3002' in .meteor/local/db/METEOR-PORT
$ meteor -p 5000
# ctrl-c in about a second: once we've wiped the old local db
# but before we've configured the new one.
# before this commit, '3002' is still in the METEOR-PORT file.
$ meteor
# before this commit, hangs with:
Initializing mongo database... this may take a moment.
(Manually ported to tool-refactoring from devel.)
Fixes#1696. Thanks to @Maxpain177 for reporting and providing access to
a machine where this was easily reproducible.
(Manually ported to tool-refactoring from devel.)
