Served index pages do not include / in their ROOT_URL either, so for
consistency we’ll remove it here too (that makes it easier to detect
when something actually changed).
- options.cwd passed through convertToOSPath
- launch processes on Windows using child_process.exec
- parse args for windows into space-delimited string
When downloading files during a Cordova hot code push, we need to
detect if a file is not available instead of inadvertently downloading
the default index page.
If we serve files with a Last-Modified based on the file date, this
interferes with content-based cache validation using ETag because
clients are required to take both into account.
We previously served non-cacheable files with a max-age of a day. This was done
to avoid image flickering on page reload (see #773).
As far as I can tell, image flickering still occurs because `location.reload`
always forces validation. But switching to `location.replace` means that max-age
will actually be respected, and we don't want to cache these assets for a day
because then changes would not be visible on reloads.
If a cached version of an asset is still fresh (depending on the `max-age`), there
is no need to send even a conditional request. Because `location.reload()` for
some reason does force validation, it makes sense to use `location.replace` instead
and improve reloading performance by avoiding unnecessary requests.
Previously, the ETag header was set (by `send`) to a default value based on the
inode of the file. Using the asset hash instead allows for proper conditional
requests even after redeployments.
To take advantage of content-based caching, we also have to disable the
Last-Modified header because having this set to the file date would still make
requests conditional on the most recent deployment. This requires updating the
send dependency and is done in a separate commit.
Fixes#626.
While processing a clean build (ie: meteor reset) this error occurs, because the platform directory exists but it empty.
Processing mobile-config.js
Writing new config.xml
Creating Cordova project
% Creating a new cordova project.
Preparing Cordova project from app bundle
Processing mobile-config.js
Copying resources for mobile apps
Writing new config.xml
Copying over the cordova-build-override directory
Adding platform iOS to Cordova project
% Adding ios project...
Adding plugin cordova-plugin-camera@1.2.0 to Cordova project
% Fetching plugin "cordova-plugin-camera@1.2.0" via npm
% Installing "cordova-plugin-camera" for android
% Failed to install 'cordova-plugin-camera':CordovaError: The provided path "/Users/horner/prj/wodrival/.meteor/local/cordova-build/platforms/android" is not an Android project.
at new android_parser (/Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/cordova-lib/src/cordova/metadata/android_parser.js:35:15)
at new PlatformProjectAdapter (/Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/cordova-lib/src/platforms/platforms.js:61:19)
at Object.getPlatformProject (/Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/cordova-lib/src/platforms/platforms.js:97:23)
at handleInstall (/Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/cordova-lib/src/plugman/install.js:563:36)
at /Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/cordova-lib/src/plugman/install.js:363:28
at _fulfilled (/Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/q/q.js:787:54)
at self.promiseDispatch.done (/Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/q/q.js:816:30)
at Promise.promise.promiseDispatch (/Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/q/q.js:749:13)
at /Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/q/q.js:509:49
at flush (/Users/horner/.meteor/packages/meteor-tool/.1.1.10.1g3vmog++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/q/q.js:108:17)
at process._tickCallback (node.js:448:13)
=> Errors executing Cordova commands:
This commit allows middleware to set the status code of the http response. This will allow a server-side router to return, for example, a '404 Not Found' response. This has SEO benefits because currently search engines may index example.org/page-that-doesn't-exist because Meteor returns a 200 OK code and the normal boilerplate response body. With a proper 404 status we can still return the boilerplate to render a client side 404 template but search engines won't index the page. Instead of a hardcoded 200 response, we call res.writeHead with res.statusCode, and fallback to the default 200 code if it has not been set.
