All the little things that add up to win.
Mimosa comes with a bunch of AMD/RequireJS support. Mimosa will...
jquery: 'vendor/jquery', or they resolve to a module, moduleX:'a/path/to/module/x'.
define and require callbacks. i.e. deferred require calls.require or define and notify you on the console.optimize flag is enabled for mimosa build, and on every file change for mimosa watch.# require:
# verify:
# enabled: true
# optimize :
# inferConfig:true
# overrides:
Path verification can be turned off using the configuration shown here. Set enabled to false. For information about how Mimosa uses RequireJS to optimize your application, check out the Optimization tab.
Path verification is always disabled for vendor assets, that is, assets located inside a vendor directory. Vendor assets often use creative means to turn themselves into AMD modules that prove hard to verify. That said, if a vendor asset is placed outside the vendor folder, Mimosa is coded to handle how some of the methods vendor assets are AMDed. But Mimosa may complain that some vendor assets are throwing errors or are not properly wrapped.
To read more about Mimosa's RequireJS support, head over to the Optimization page.
Mimosa's RequireJS support comes from the mimosa-require module, a default Mimosa module that comes installed with Mimosa. For more on modules, see the Modules page.
To 'lint' code is to check it for common mistakes or variances from the idiom. Mimosa will automatically lint all of the CSS and JavaScript it moves from source directories to compiled directories. Any errors or warnings that come out of linting will be printed to the console but will not stop or fail the compilation. Inside the mimosa-config is the snippet to the right which controls the linting. As with all of the default config, this is entirely commented out as the defaults are already enforced.
Mimosa's Linting support comes courtesy of the mimosa-lint module, a default Mimosa module that comes installed with Mimosa. For more on modules, see the Modules page.
The compiled block controls whether or not linting is enabled for compiled code. So when Mimosa compiles SASS, LESS or Stylus, Mimosa will send the resulting CSS through a linting process. Similarly for the JavaScript meta-languages, Mimosa will lint the resulting JavaScript.
The copied settings determine whether or not to lint copied files, like hand-coded JavaScript.
# lint:
# exclude:[]
# compiled:
# javascript:true
# css:true
# copied:
# javascript: true
# css: true
# vendor:
# javascript: false
# css: false
# rules:
# jshintrc: ".jshintrc"
# js:
# plusplus: true
# css:
# floats: false
Mimosa also allows control over the linting of code contained in the vendor directory. Linting is, by default, disabled for vendor assets, that is, those assets living inside a /vendor/ directory. Vendor libraries often break from the idiom, or use hacks, to solve complex browser issues for you. For example, when run through CSSLint, Bootstrap causes 400+ warnings.
To enable vendor asset hinting, uncomment enable the setting and switch the flags to true.
The rules block is where linting rules for each of the linting tools are overridden or changed. Example overrides are provided in the default configuration. Those are examples, they are not actually overrides.
For CoffeeScript and IcedCoffeeScript some jshint rules are turned off by default. Those compilers output JavaScript that violates jshint and there is nothing that can be done other than turn the rules off. So when compiling those files, Mimosa will turn off the following rules by default:
boss: true eqnull: true shadow: true
Both of the lint/hinters come with default configurations that Mimosa uses. Here are links to the tools, as well as to the configuration for those tools.
Mimosa provides live reload support by default via the mimosa-live-reload module. Live reload will immediately refresh a page any time an asset is compiled or a view changes.
mimosa-live-reload handles CSS and JavaScript assets differently. For CSS the page does not need a full reload. The new CSS is re-evaluated without reloading anything other than the CSS. The page is simply repainted. When JavaScript assets are updated, the entire page refreshes.
This sounds like a fairly small nice-to-have feature, but it quickly becomes one of the handiest time savers in your workflow. Mimosa and Live Reload are often fast enough to get the page reloaded before the browser can be toggled to.
If mimosa new was used to create the project, then live reload will already be included. If enabling it on an existing project, some minor things need to change on both the client and server to use it.
For live reload to work, two scripts need to be added to the page. If using dynamic templating for views, then the scripts need to be included for development and not included when in production.
The paths to use for the two scripts are:
/socket.io/socket.io.js: This is socket.io. Mimosa will serve this file, so it need not be in the project's codebase, but a script tag must pull it in. socket.io is what allows instant communication of server-side changes to the client. socket.io will emit events on the client that indicate that a JavaScript file has changed, or a CSS file has changed./javascripts/reload-client.js: This is a small piece of code that reacts to events emitted by socket.io. When it hears from socket.io that a piece of CSS has changed, it reloads the CSS. When it hears that some JavaScript has changed, it refreshes the page.If Mimosa is serving assets, there is nothing to do on the server.
If running a node server that Mimosa is starting, then the callback that Mimosa passes startServer needs to be passed the http server object. This is the same object returned by require('http').createServer() and by express().listen(). The mimosa-live-reload module needs access to the server to establish a connection between the socket.io client and the server.
This pertains to those who are using their own server, not Mimosa's. The mimosa-live-reload module uses socket.io in conjunction with the server passed to the startServer callback function to provide live reload functionality. But if socket.io is already being used, Mimosa's use of socket.io will cause problems.
If socket.io is already being used, then it must also be given to the callback function executed at the end of startServer. The first parameter passed to the callback should be the server, and the second should be the object returned by socketio.listen(server). If this object is provided, mimosa-live-reload will not create its own socketio connection, and instead use the existing one.
Via an external module you can restart your server anytime certain files change. This is yet another time saver.
Compilation of assets is kicked off as soon as a file is saved. Mimosa will write to the console the outcome of every compilation event. Should compilation fail, the reason will be included in the log message.
If Growl is installed and turned on, a Growl notification will be created for each failed or successful asset compile. In the event Growl gets too spammy, Growl notifications can be turned off for successful compiles. Growl has its own setting in Mimosa, the defaults are to the right.
If clean in run on a project and then watche is started, Mimosa will compile every asset. If there are dozens or hundreds of assets, Growl notifications may not be desirable for each successful compile during startup. Startup success notifications are off by default, but can be turned on by uncommenting the config and setting the growl.onStartup flag to true.
# growl:
# onStartup: false
# onSuccess:
# javascript: true
# css: true
# template: true
# copy: true
Post-startup success notifications can be turned off for compiled javascript, css, and templates, as well as for copied assets by altering the growl.onSuccess flats. These notifications are on by default.
All static assets will be served up GZip-ed! 'nuff said.
No forcing a refresh to bypass caching issues. All JavaScript and CSS files are cache-busted during development.
JavaScript cache-busting is done via the urlArgs parameter with RequireJS. That can cause some problems if you are doing breakpoint debugging in the client. You'll want to comment out the urlArgs if you do that kind of debugging.
Profiles allow for overriding of mimosa-config settings via external config files. A project might have a "build" profile that is used for automated builds, and for those builds maybe certain modules aren't needed. For instance the "lint" module can be left out of the modules array.
Profiles are implemented as mimosa-config files. Any properties of a project's mimosa-config that need to be overridden would be the properties placed in a profile file.
By default, profile files should be located in a profiles/ directory at the root of a Mimosa project. This location can be overridden via the profileLocation property in the project's mimosa-config. profileLocation is relative to the root of the project.
Profiles can be used for the watch, build, clean and virgin commands. Each of those commands have a -P/--profile flag. Follow the flag with the name of the profile to use and Mimosa will pull that profile in and use it to override the settings in the mimosa-config. Ex: mimosa build -P build.