Hey guys! Been out and about. Backing all the way back to the RequireJS CSS thing...
One of the things that Mimosa (mimosa-require) does that I am really proud of is 1) build the r.js config and then 2) give you (modules) a chance to slide in and make changes to the r.js config that Mimosa has built before 3) mimosa-require runs the optimization. It makes it very easy for modules to add some of what they know to the r.js config before the r.js optimization runs. This module does that: https://github.com/dbashford/mimosa-requirebuild-textplugin-include
So if a module existed that was smart about the CSS stuff, and if r.js and it's builds could do something with the CSS stuff to help you, then that's a good place. If a separate module were able to do that work, that's where I'd prefer it to be. mimosa-require already does a lot. it does nothing with CSS right now. so another module is best.
hey @anachron -- that skeleton didn't work for me ... Are you sure you have all the server portions wired up correctly? The server routes don't seem to be working ...
On the gulp/broccoli streaming stuff, I've mentioned a few times, streaming only seems important because the other options (besides mimosa and to some degree brunch) have been slow. Grunt is slow. Gulp did streams. Streams are fast. A few important people got behind it and it spread fast. There are other ways to be fast without doing streams. Mimosa is not as fast as gulp, but when the difference is 1ms vs 10ms... do you really notice? You don't. The problem with Grunt isn't that it doesn't stream. Streams are just one solution. The problem is that Grunt makes constant writes to the file system because its modules can't talk to one another or share inputs/outputs. Mimosa solved that problem 18 months ago.
I don't feel any urge to alter the way Mimosa's workflows are strung together. It works great. Of all the things people complain about or wish were different or want to have added, none of them have anything to do with how Mimosa solves its input/output module-chaining behavior.
I do admit to not digging deep into Gulp. I've played with it a little just to gauge speed. I haven't looked at broccoli at all. I've had shared with me some comments from the folks behind broccoli that it isn't the right tool for something like JSHint because JSHint doesn't have inputs and outputs, it just scans code. And maybe one would need gulp or grunt running along-side broccoli. That by itself would be enough to turn me off to it. But again, as little educated on Gulp as I am, I'm much less educated on broccoli, so I could be way off or misunderstanding things entirely.
Full support from me :). I only mentioned that broccoli blog because the broccoli author explicitly compared the broccoli approach to gulp/grunt -- but didn't compare broccoli to mimosa ... As I was reading the article I was looking forward to reading the comparison to mimosa (to see if there was any reason I should care about broccoli ...) and then there was none ... It makes wonder if the ember folks didn't know about mimosa before they started rolling their own -- or if they are just guilty of 'not invented here' syndrome
I wish the ember folks had taken a look at it. But I get that they rather go with something from their own community of folks. I believe the broccoli author is very much a known commodity in the ember community. Ember is a big deal. If Ember itself decides broccoli is their build tool (I haven't seen it endorsed, just publicized) , that too is a big deal. Picking Mimosa for that, or even getting behind it, might be hard for them if they don't know me from anyone else.
There's already a grunt-broccoli plugin actually =). Kind of odd to me.
Someone needs to make a Yeoman Mimosa generator =p
haha
Err, Mimosa Yeoman generator?
It actually makes more sense then you'd think, oddly enough.
you want a yeoman project that spits out a mimosa config? sneaky
I saw a Gulp generator pop up real quick.
has anyone come across a mimosa module that helps manage api keys -- and other things that need to be kept secret/not checked into source control
?
I don't think there is any.
hmm ok -- I'm going to try to build a mimosa module around this project -- https://github.com/jcoglan/vault/tree/master/node
My thinking -- the module should have two config options -- 'extension' which will default to [".vault.js", ".vault.coffee"] and 'secretpath' which will default to ~/.mimosa/vault/{projectname}.key files which end with matching extension should export an object which maps a list of service:string -> username:string -- representing a username/api key for which a secure password should be derived. The module will process these .vault.{coffee,js} files into a new json file which maps 'service'->['username', 'vault_derived_secret']
The file at secretpath should be an ssh private key
mimosa vault:new-key will generate a new ssh private key (warning before overwriting an existing key)
(sorry to spam the list with my brainstorming ... -- i'm done and will go try and make this now)
is there a good way to get at the package.json for a project from within a mimosa module? I want to extract the project name field from there ... I looked at mimosa-web-package -- which does this:
pack = require(path.join config.root, 'package.json')
tarballName = pack.name if pack.name?
I think that works ... is it sane pattern for other modules?
config.root is always the root of the project, that is, it is always where the mimosa-config sits
@breathe: About the skeleton: There is only the index page so far, it's a work in Progress :)
@dbashford about the CSS injection into requireJS: Yeah, definitely another module. There are a lot of extensions of requireJS to include text or especially CSS-sources. I decided to give this a try https://github.com/guybedford/require-css since the author name is similar to yours :D
@breathe: Require is the best way to do what you want, but package root is always the same, also, you should notice that require will not reread the config if it changes until you restart the program.