Mimosa comes with a bunch of AMD/RequireJS support. Mimosa will...
jquery: 'vendor/jquery', or they resolve to a module,
requirecallbacks. i.e. deferred
defineand notify you on the console.
optimizeflag is enabled for
mimosa build, and on every file change for
# 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.
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.
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
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.
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.
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.
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:
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
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.onSuccess flats. These notifications are on by default.
All static assets will be served up GZip-ed! 'nuff said.
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
profileLocation is relative to the root of the project.
Profiles can be used for the
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 build -P build.