FAQ & Mimosa Tips

Having trouble? We'd like to help! Here are a few ways to get some help:

• Reach out on Twitter.
• Post on the Mimosa Google Group.
• Add an issue on GitHub.
• Join us on the Mimosa Gitter chat.

2.1 upgraded logging in a major way. There are just a few things to keep in mind when upgrading.

• All of the modules have been updated to use the latest logging functionality. The newest modules must be used with Mimosa 2.1 as they expect Mimosa to pass them the logger. Using the most up to date modules with older versions of Mimosa will result in errors.
• Version 2.1 will work fine with older versions of modules except that the logging messages will bounce back and forth between the new logging (mimosa core 2.1) and the old logging (from the module).
• If you were using (overriding) the growl.onsuccess flags, you'll find those flags are no longer available. They have been removed.

2.0 brings the externalization of Mimosa's JS/CSS/Template compilers. This slims down Mimosa's footprint, speeding up installs, and greatly simplifies the Mimosa codebase. Externalizing the compilers also sets Mimosa up for other contributors to very easily create new, external compilers of their own. Previously that would have entailed pull requests back to the main Mimosa library.

Only config changes are necessary to upgrade to 2.0.

• Each of Mimosa's JS/CSS/Template compilers now have their own Mimosa module. If using any of them, they need to be added to the mimosa-config modules array. For instance, if using CoffeeScript, Stylus and Handlebars, "coffeescript", "stylus", "handlebars" will need to be added to the modules array.
• Mimosa's "copy" compiler was also pulled out of Mimosa's core. That compiler handles any files that go through any sort of transpiling or preprocessing. If using images, .js or .css files, add "copy" to the modules list. It will be a very rare project that doesn't need to add "copy" to the list.
• Using the compiler config? That is going away. Each compiler module has its own configuration, including the ability to provide a specific version of the compiler and change the extensions being used for the compiler. For details on each compiler's config, check the README on that compiler's github page. For instance, here is the LiveScript README.
• The Handlebars compiler has been pulled out into two separate compilers, one for those using ember.js, and those who are not. This removes the need to specifically configure ember. Instead of configuring ember, just use the ember specific compiler. The ember-handlebars and handlebars github pages have details on how to configure those new modules.
• The mimosa-server module now depends on the project to have the correct transpilers npm installed to use those transpilers for node.js server code. So, for instance, if LiveScript is being used on the server, then LiveScript must be npm installed into the project.

Using Bower? Bower fetches scripts and libraries from GitHub which means it has a dependency on git. If you don't want to install git, then you cannot use Bower. That isn't a problem! Just remove "bower" from the list of modules in your mimosa-config.

If you have a lot of files, or are using multiple watchers (like mimosa + mimosa-import-source), you might find your CPU pegged and things bogging down. Both mimosa core (watch settings) and mimosa-import-source have intervals you can provide it to keep it from polling the file system too often. For details, check out the GitHub issue where this was discussed.

You can also try turn off polling altogether by turning usePolling to false. This might be the best option if you have truly enormous projects.

node.js is fast. Wicked fast. Sometimes too fast for its own good. If you have a large project with many files (usually 200+) that Mimosa has to move from one directory to another on startup, Mimosa will attempt to process all your files at once and may attempt to open more files than your system allows. When that happens, you'll see an error like this:

child_process.js:922
throw errnoException(process._errno, 'spawn');
^
Error: spawn EMFILE
at errnoException (child_process.js:975:11)
at ChildProcess.spawn (child_process.js:922:11)
at exports.spawn (child_process.js:710:9)
at Object.exports.execFile (child_process.js:602:15)
at exports.exec (child_process.js:573:18)

This problem is why the watch.throttle setting was created. Check it out on the Configuration page.

I see search engine traffic coming to the Mimosa site having used the search term "mimosa without requirejs" quite a bit.

Mimosa's mimosa-require module certainly provides a lot of sugar for RequireJS users, but Mimosa is absolutely usable if you aren't using RequireJS. There are other module loaders you can use, like Browserify, or you can not use a loader module at all.

The key changes to any Mimosa project not using RequireJS are

• Remove the require module from the list of configured modules
• Script tags need to be added to the pages that need those scripts since RequireJS' module loading will not be able to pull in files for you.

Check out this example project which leverages all the goodies of Mimosa without using RequireJS.

Want to push your app to Heroku? Here's a few steps to go from no app to a Heroku app in no time at all. The following assumes you have signed up, you have the toolbelt installed, and you have git installed as Heroku deploys code via git.

Initial Setup

Many of the following tasks only need to be executed once.

1. Execute mimosa new and pick your favorite technologies. You must pick a server.
2. Open the mimosa-config, uncomment the modules array and add 'web-package' to the end of the array. Note: If you already had web-package installed, you'll want to make sure to upgrade to the latest version. The best way to do that is to change the entry in the modules array to web-package@0.8.0. 0.8.0 is necessary for maximum Heroku support.
3. Open .gitignore and change /dist to # /dist. This makes the dist directory, which is created by the web package module, something that gets checked in.
4. In the root of the project, create a file named Procfile, no extension. The content of this file should be one line: web: node dist/app.js. This lets Heroku know how to start your app.
5. Run mimosa build -omp. This minifies, optimizes and packages up the code.
6. Run heroku login and provide your credentials
7. Run the following git commands: git init, git add ., git commit -m "init"
8. Run heroku create, which sets up the remote repo with Heroku
9. Now push your code! git push heroku master

At the end of the console spam from Heroku will be the URL to your app.

After Initial Setup

Once you are passed the initial setup, the list of steps shrinks dramatically. Now its just a git repo and you need to build your app.

1. Run mimosa build -omp
2. git add ., git commit -m "init"
3. git push heroku master

Peter Morlion wrote an excellent blog post on how to get up and running with a Mimosa node.js application in Azure. His example includes a specific UI framwork, but the steps he took are universal.

require.js allows you to bundle your application up into single files for production builds. But what if you want to bundle your application into several small files rather than a single one?

A common question from Mimosa's require.js users is how to configure the mimosa-require module to handle dynamic modules. The MimosaDynamicRequire example application illustrates how to do that.