there should be a 'lein dieter-precompile' plugin for leiningen

[pbiggar]

I working on this at https://github.com/circleci/lein-dieter-precompile. No code yet, just a README, but comments appreciated (including whether it should be a separate project or if it should be included in dieter).

[jxa]

I've been thinking about this a bit. I'm leaning towards the idea of using the precompile task as a complete replacement for the current "production" mode of dieter.

I'm targeting a solution for a couple of problems:

• Slow initial load of asset
• unable to deploy via uberjar

My thought is that dieter would be used exclusively in development. Assets would be compiled and served directly by dieter. Not the way it currently writes to the filesystem and then passes to ring's wrap-file. A lein task would be used to precompile before a jar is built (is it possible to make the jar task dependent on the dieter-precompile task?). The lein plugin would need to know which assets to build. Something like

:dieter-precompile [
  "javascripts/app.js"
  "stylesheets/app.css"
]

The assets would be compiled into asset-cache at that point. The user would then need to include ring's wrap-resource for that directory so that the compiled files could be served in production without a dieter dependency at all.

I'm thinking the lein plugin and the normal dieter functionality should live in the same project.

Comments / questions welcome.

[pbiggar]

Replacing the production mode makes sense,but I would be wary of the problem in Rails: things work in development and break in production.

I would suggest just precompiling all assets. It'll lead to a few extra assets, but that's no harm.

What would happen to dieter's mime type mappings if you replace dieter's middleware with ring's wrap-resource?

Grand, we can integrate the two projects, with the lein plugin as a subdirectory. I'll integrate them as soon as I have it working.

[TravisTheTechie]

+1 on seeing this.

[pbiggar]

This has been merged into master.