`__meteor_bootstrap__.bundler` => `__meteor_bootstrap__.bundle`
`bundle.bundle_dir` => `bundle.root`
Rather than placing app_info/appInfo containing the manifest in the
bundle object, instead I'm now placing the manifest directly in the
bundle object. A) no code currently uses bundle.appInfo.load; B) if
someday we expand the manifest to also include server side resources
than we'd be getting rid of `load` anyway; C) I think it reads better:
`bundle.appInfo.manifest` => `bundle.manifest`
cp_r now returns a list of os-specific relative file system paths as
strings, instead of paths as arrays.
I changed the normalized "path" field in the manifest to be a relative
path instead of an absolute path (`"/static/cat.jpg"` =>
`"static/cat.jpg"`). This felt better when looking at the manifest; I
think because the path is relative to the bundle root.
Creates a manifest of the static files delivered to the client, for use
by the app cache. The manifest is also designed to be usable to generate
etag's for issue #626.
In the original bundler code `self.css` and `self.js.client` starts
out as an array of os-specific file paths and later becomes an array
of URLs (including query parameters). While I tried to minimize code
changes to avoid creating extra work for the engine project, this
turned out to be too crazy to deal with. In this version `self.css`
and `self.js.client` stay as file paths, and _generate_app_html now
pulls the client URLs from the new manifest.
This PR is thus proposing a design where the bundler manifest becomes
the source of knowledge about client static resources included in the
bundle, and is then used to generate the app html, the app cache, and
perhaps etag's in the future. (If it made sense then the `load` list
of server Javascript files could also be folded into the manifest,
making the manifest the source of knowledge about all static
resources... but the code in this PR don't include any steps in that
direction).
This definitely won't "work" because both have API changes.
UglifyJS 1 was having issues minifying certain code (eg lodash). But UglifyJS 2
was occasionally segfaulting (as was other code using large regexps). See the
bottom of https://github.com/laverdet/node-fibers/issues/89
Hopefully this will fix it.
The 'exit' event on a ChildProcess doesn't necessarily occur before all the
'data' events on its stdio, so sometimes 'meteor mongo' didn't find the
process. We should have been using the 'close' event. Switch from
child_process.spawn to child_process.exec, which simplifies the code and uses
the right event.
Also make sure that every use of app_dir that eventually gets passed to
_scan_for_sources is a resolved path. (Maybe should just resolve in
require_project instead?)
