Implements https://github.com/meteor/meteor/issues/6537#issuecomment-205954797
The setup.sh script was only sometimes written previously, so no existing
deployment logic should rely on it existing.
On the other hand, all apps built by `meteor build` require running
`npm install` in the programs/server/ directory, so the install hook I
added to programs/server/package.json will ensure npm-rebuild.js is
invoked reliably.
Using a pure Node script means this code will work just as well on Windows
as on Linux or Darwin, though Linux is by far the most common deployment
platform for Meteor apps.
TODO Remember to rebuild the dev bundle before the next release!
This reverts a change I made in 75f9214959.
I thought allowing partial paths would make files.pathRelative more
robust, but it had the unintended consequence of causing #6586.
For package dependencies, the node_modules directory immediately follows
the /package/ part of the path, but for plugins the name of the plugin
comes before the node_modules directory.
Because symlinking is impossible on Windows, and copying node_modules
files is too slow, we can't just symlink/copy all node_modules files into
.meteor/local/build/programs/server/npm like we do for other platforms, so
we have to search for them where they are.
Part of #6500.
- Split files into the correct place, given the guide
- Import html file
- Removed test [it's not a demo]
- Use ReactiveVar rather than Session
- Added an info section to guide people further
Note that `export default` no longer modifies `module.exports`, but simply
defines `exports.default`, so these two import styles will work:
import DefaultExport from "./export-default-module.js"; // preferred
var DefaultExport = require("./export-default-module.js").default;
but this style will no longer work:
var DefaultExport = require("./export-default-module.js");
This adds `appId` to the `config.json` generated by the bundler, and uses that
in `boot.js` to initialize `process.env.APP_ID`. This is used by `autoupdate_server.js`
to set `__meteor_runtime_config__`.
Specific improvements:
- Parentheses are now stripped from commands that look like named classes
so that they will be treated as class declarations rather than as named
class expressions.
- When the `ecmascript` package is installed, `compileForShell` errors are
now exposed to the `evalCommand` callback.
- Instead of using `vm.runInThisContext` to parse and evaluate commands at
the same time, `evalCommand` now parses commands by creating a new
`vm.Script` and later evaluates them using `script.runInThisContext()`,
so that `SyntaxError`s can be reported immediately. Fixes#5131.
Discussion/plan here: https://github.com/meteor/meteor/pull/4851
`meteor-platform will no longer be a part of future Meteor releases. Apps
`upgraded to Meteor 1.2 will be automatically updated to use the packages listed
`above instead of meteor-platform. (Along with a set of packages like EJSON and
`Random that used to be in meteor platform but probably shouldn’t have been)
After this project, here is the set of packages that will be included by default
in a newly created Meteor app:
1. `meteor-base` is the set of packages that basically every single Meteor app will have. If you don’t have these packages, you are probably doing something that isn’t really supported, like building a command line tool or switching out the whole web server stack. It comes with the following packages:
1. `meteor` - this includes stuff like `Meteor.isClient`, a default handler for `css` files, etc.
2. `webapp` - this is responsible for handling actual HTTP connections, Websockets, and serving files
3. `underscore` - almost all of Meteor is built on top of underscore, so it makes sense to let people assume that most or all Meteor apps right now will have this included
4. `autoupdate` - refreshing the client is a core part of the Meteor development experience, and it’s integrated into several layers of the stack
5. `ddp` - lots of core parts of Meteor assume that DDP can be used to communicate between client and server
2. `standard-minifiers` minifies your JS and CSS code in production
3. `ecmascript` allows you to write your app using new ES2015 JavaScript features
4. `es5-shim` polyfills some newer APIs in old and non-compliant browsers, in particular IE8
5. `mobile-experience` is a set of cordova-specific packages that set some good defaults when building for mobile. These packages only activate when you are building a native Android or iOS app.
1. `fastclick` - avoid the 300ms touch delay
2. `mobile-status-bar` - avoid the status bar information covering up your app content
3. `launch-screen` - cover the app with a launch image so that people don’t have to see things loading
6. `mongo` is the package that enables Meteor to connect to MongoDB on the server and watch queries in real-time. It also includes Minimongo for the client so that you can publish Mongo documents over DDP. This package will be removable in case you want to use one of the community-supported drivers for alternate databases, and for the desirable future where Meteor supports other databases officially.
7. `blaze-html-templates` compiles your `html` files with Spacebars and includes the Blaze runtime on the client so that the templates can run. If you remove this, you might want to include a different view layer like `react`, or `angular`, and use a package for rendering the starter HTML like `static-html` (also coming out in Meteor 1.2)
8. `tracker` the package that powers a lot of Meteor’s reactive APIs on the client. Including it in the app allows you to use `Tracker.autorun` directly.
9. `session` a simple global reactive dictionary for the client.
10. `jquery` a convenient utility library for the client.
11. `insecure` a prototyping package that lets you make any database modifications from the client.
12. `autopublish` a prototyping package that lets you access the whole database (except sensitive user data) from the client.
