3cfb718a91
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.
Meteor Tool
This part of the code-base is Meteor's CLI tool that reads commands from the user, builds the application, adds runtime code, provides an interface to Meteor Services (Accounts, Packages, Build Farms, deployments, etc).
The Meteor Tool is designed to be the "minimal kernel" as most of the functionality that goes into a typical Meteor app can pulled from core and 3rd-party packages.
Getting set up
Using Meteor in development is very simple. If Meteor spots that it is running
from a Git checkout folder (having a .git directory), it will run in dev mode,
download npm dependencies dynamically and pull the latest dev_bundle on the
first run.
dev_bundle is a tarball with prebuilt binaries (node, npm, mongod, etc)
and npm modules necessary for the Meteor tool. dev_bundles are versioned and
are built with a script in the admin directory. It is commonly built on
Jenkins.
Usually it doesn't take long to get a new dev_bundle but if you are on a
spotty network or switching between branches referencing different versions
often, you can set the environment variable that will cache all downloaded
versions indefinitely:
set SAVE_DEV_BUNDLE_TARBALL=t
You can also run ./meteor --get-ready to install all npm dependencies for the
tool.
Testing
Since the tool is a node app, it is not testable with general Meteor testing tools such as Tinytest or Velocity. Instead the home-grown system "self test" is used.
"Self test" is a testing library that is focused on testing the CLI interactions and is rather an end-to-end testing tool (not a unit-testing tool). Albeit, it is often used for testing individual functions.
Besides monitoring the process output, "self test" is capable of moching the package catalog, running from template apps.
The asserting syntax of "self test" is rather unusual since it operates on the process's stdout/stderr output after the process has run (not in real-time). A lot of assertions depend on timeouts and waits.
To run all tests, run the following:
# download all npm dependencies, etc
./meteor --get-ready
# set the multiplier for time-outs
SET TIMEOUT_SCALE_FACTOR=3
# run the tests
./meteor self-test
Note, the scale factor for time-outs might be different depending on the hardware, but 3 is a safe choice for automation.
To quickly run an individual test or a group, pass a regular expression as an argument, it will be matched against test names:
./meteor self-test "login.*"
You can also run a particular file, or list all tests matching certain
pattern, run with phantom or browserstack.
See more at ./meteor help self-test.
Profiling
Profiling is done in an ad-hoc way but it works well enough to spot obvious differences in things like build performance.
To enable profiling, set the environment variable to a "cut off" point, which is 100ms by default.
set METEOR_PROFILE=200
In this case, the reporter will only print calls that took more than 200ms to complete.
Internally, every profiled function should be wrapped into a Profile(fn) call.
The entry point should be started explicitly with the Profile.run()
call. Otherwise, it won't start measuring anything.
Debugging
Currently, debugging the tool with node-inspector is only possible if you edit
the meteor bash/batch script and add the --debug or --debug-brk flag to
the node call. Note that node-inspector should be compatible with the node
version in the dev_bundle.