2.1 upgraded logging in a major way. There are just a few things to keep in mind when upgrading.
2.1as they expect Mimosa to pass them the logger. Using the most up to date modules with older versions of Mimosa will result in errors.
2.1will 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).
growl.onsuccessflags, 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
modulesarray. For instance, if using CoffeeScript, Stylus and Handlebars,
"coffeescript", "stylus", "handlebars"will need to be added to the
"copy"to the modules list. It will be a very rare project that doesn't need to add
"copy"to the list.
compilerconfig? 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.
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
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
requiremodule from the list of configured modules
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.
Many of the following tasks only need to be executed once.
mimosa newand pick your favorite technologies. You must pick a server.
mimosa-config, uncomment the
modulesarray and add
'web-package'to the end of the array. Note: If you already had
web-packageinstalled, 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
0.8.0is necessary for maximum Heroku support.
# /dist. This makes the
distdirectory, which is created by the
web packagemodule, something that gets checked in.
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.
mimosa build -omp. This minifies, optimizes and packages up the code.
heroku loginand provide your credentials
git add .,
git commit -m "init"
heroku create, which sets up the remote repo with Heroku
git push heroku master
At the end of the console spam from Heroku will be the URL to your app.
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.
mimosa build -omp
git add .,
git commit -m "init"
git push heroku master
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?