Now instead of calling `catalog.getLatestMainlineVersion` when printing
messages about non-latest versions in `meteor update` with no args,
we use the same logic from `meteor list`.
Band-aidy, but fixes the case when two packages add the same plugin with
the same version that can't be parsed by semver (like github url).
For some reason, after the build plugins refactoring the same plugin
from the same package can now be added twice from `webapp`.
Since this feature is not well designed to begin with, decided to spend
too much time investigating it.
We've been shipping the `logging` package to the client even though it
isn't used on the client by any core packages. Now that the `logging`
package is removable from your app, let's make it actually removable
by deleting totally worthless dependencies that exist for bizarre
historical reasons.
For example, some packages, like `reload` and `mongo`, depend on
`logging` because that's where `Meteor._debug` used to be, before it
was moved to the `meteor` package and `logging` was repurposed for
something else. The `ddp-server` package had a crazy overreaching set
of dependencies, pulling in a bunch of client-side libraries even though
it only has server-side code of its own.
JSON support is in all browsers we could conceivably care about; it's
ES5 and has perfect support in IE 8. No need to ship a library as
a core package, and no need to specify dependencies on it.
We could conceivably publish a new version of the `json` package that
is empty, so that apps using packages that still say `use("json")`
also get the code size reduction, but we'll wait until someone requests
that.
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.
