Am I tied to Node when using Mimosa?

[jeffijoe]

So I got Mimosa installed yesterday and tried to set up a new project. I will be using PHP in my views, as I am tied to a shared Linux webhost.

Running Apache (Xampp) on my Windows machine, I'd like to develop that project blazingly fast using all the awesome Mimosa provides. Thing is, once Mimosa spit out the views and assets folder, I don't know where to start, it seems Mimosa is hinting towards using pure JS. Should I just delete the views folder at create an index.php in my project root? Do I need to have a flag in my PHP code that determines if I am in dev or production mode, so I know when to use the built assets or the dev ones?

Long story short: For a plain-vanilla PHP "site", where do I start?

[dbashford]

At my 9-to-5 we have Mimosa sitting on Rails, so nope!

This question made me realize that while mimosa new has a none option for server, that option really just translates to Mimosa serving for you. I need a real none that doesn't bother giving you any server stuff and tells you what you ought to do next.

So, what you ought to do is nuke all that server stuff, obviously you don't want it and you definitely don't need it. Also, remove server from the modules array as its functionality is lost on those not using node-based servers in someway, either via Mimosa or via your own. You'll unfortunately also need to remove live-reload. That uses socket.io via node under the hood.

What we do is we have a project structure like this...

/ui
  /server
  /client

Inside the client lives all that Mimosa tends to. Inside server is the backend to our Rails app. Rails has a public directory where it expects to find all of its assets. So the mimosa-config sitting inside client just points at it.

exports.config =
  ...
  watch:
    compiledDir: "../server/public"
  ...

I assume PHP has something similar you can use? That should be it.

FWIW, we also use node. Inside the client directory we have an Express server that we use for the guys to run mock, canned end-points. We can only access the development data from a specific location, so we set up an Express app so the guys can work from home or the coffee shop. Just the same end-points that Rails has, except they just return canned JSON as responses. Embarrassingly simply to set up. The guys do most of their dev this way and then pull things together on Rails every so often. A side benefit is it lets them take advantage of things like live-reload.

[jeffijoe]

LiveReload can be used separately, that's no problem.

What I'm interested in, is a way to have a vanilla-php setup, like so:

/js
/css
header.php
footer.php
index.php
contact.php
about.php

Maybe Mimosa is overkill for this?

[dbashford]

That's pretty much what I just explained. So you could have this...

/assets
  /js
  /css
/public
  /js
  /css
header.php
footer.php
index.php
contact.php
about.php

That'll just work. 95% of what Mimosa does is browser related. The server hooks are convenience. The browser stuff is the meat. So you'd run mimosa watch along side whatever you need to do to run PHP and in your PHP you'd point at /public/js/* and /public/css/*.

Your pre-compiled code would live in assets, so, for example, Coffee, Stylus, Handlebars, and it all gets compiled/copied to public.

[jeffijoe]

Ah, ok! Thanks!

I got 2 other things, not big enough to justify a new issue.

1: I don't seem to be able to locate any configuration for setting the stylesheets folder name. It seems to be locked to "stylesheets".

2: I am not a fan of CoffeeScript - is there a way that I can run regular javascript with requirejs in development mode, but use a main-built.js in production? And the same for CSS? That's the biggest reason to using Mimosa for me. :)

Thanks for your time. :)

[dbashford]

1. You can put stylesheets anywhere inside the watch.sourceDir. If Mimosa comes across a "assets/foo/bar/baz/style.styl, it'll compile it topublic/foo/bar/baz/style.css. It is a good idea to configure where the vendor stylesheets are usingvendor.stylesheets`.
2. That just works. Mimosa doesn't care what you use. It'll just copy your JavaScript from watchDir to compiledDir and along the way do all the other stuff, like linting, requirejs path validation.

[jeffijoe]

And I guess you only do the complete build when you're about to release then? (to get a compiled main.js file?)

About the vendor stylesheets - Bootstrap.css would be a vendor stylesheet, but so would, e.g. bootstrap-select.css - but bootstrap-select.css depends on bootstrap.css to be included first. How does Mimosa handle that?

Thanks again! :)

[dbashford]

Mimosa doesn't come bundled with any CSS combiner/concatenators besides the ones that come built into things like Stylus/Less.

One of the most popular external modules though is mimosa-combine which can manage that sort of thing for you.

You can run mimosa watch -o to build the optimized files and then keep watching. When you change code, the files will rebuild. So you can dev that way if you wish. I tend to only do that though right before doing a final pre-release mimosa build to make sure everything is good.

[jeffijoe]

Ok, got it! Thanks!