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.
Changes to packages/callback-hook:
- Add bindEnvironment option to Hook constructor (defaults to true).
- Add internal helper function dontBindEnvironment() which does all the
error handling stuff like Meteor.bindEnvironment() but doesn't change
the environment.
- Use dontBindEnvironment() instead of Meteor.bindEnvironment() when
bindEnvironment option is false.
- Add tests.
Changes to packages/accounts-base:
- Create hooks with { bindEnvironment: false }
- Add test for whether Meteor.userId() is available in login callbacks.
Also, "marketing material" doesn't seem like an accurate description of the page on the Meteor site as it's more of a high level description of the component.
1. Make a package called `static-html` that just compiles `<head>` and `<body>` tags inside `.html` files. Much like templating but without the templates.
2. Refactor `templating` to avoid duplicating code.
Split out code that would be shared between `templating` and `static-html` into a new `templating-tools` package. These tools could also be used to simplify implementation of other build plugins, like `simple:markdown-templating`.
This also has the added benefit of moving as much code as humanly possible out of the `templating` package, so that it can be reused in other packages.
1. `templating-tools` package and its README
2. `static-html` package and its README
3. `caching-html-compiler` is not new code; it is just code factored out of the batch plugin version of `templating`, but the README and some comments are new.
1. `tools/tests/static-html.js` tests static html and error handling
2. `templating-tools/html-scanner-tests.js` tests `scanHtmlForTags` and `compileTagsWithSpacebars` together.
All unit tests pass on this branch.
