Closed breathe closed 10 years ago
I see the option to control this is templates.commonLibPath
https://github.com/dbashford/mimosa-handlebars/blob/master/src/index.js#L57
Is it strange that this is part of the template config instead of the handlebars compiler config ... Somehow that seems odd to me ... given that I could set handlebars.lib = require('handlebars') and additional configuration of the generated commonjs output ends up still being required or the generated module won't work ...
Not sure if I should close this issue -- I'm pasting the 'correct' config below -- but I think there is a question whether template.commonLibPath should need to be set explicitly when wrapType='common' ... I'll let you close if you think no changes are warranted.
In case anyone comes across this -- the appropriate mimosa-config for this is:
exports.config =
modules: ["jshint", "coffeescript", "handlebars"]
coffeescript:
options:
bare: false
watch:
sourceDir: "src"
compiledDir: "lib"
javascriptDir: "./"
jshint:
rules:
node: true
template:
outputFileName: "templates"
wrapType: "common"
commonLibPath: 'handlebars'
You'll remember back a ways when all the template compilers lived inside mimosa. When I broke them out, I had to decide, do I duplicate all of these settings inside each template compiler, or do I keep the template compilers a little more lean and keep things that make sense inside template, which means managed by mimosa core's validation, etc.
For why commonLibPath
is needed, two things to keep in mind, 1) mimosa still contains a bit of a slant towards AMD/require and 2) Mimosa has always been a browser dev tool first; the fact that you can do server dev is a happy accident.
While Mimosa has grown beyond it a bit, it's still slanted towards AMD dev. mimosa-require is the biggest and most powerful module in the module set. So there's not been a need to provide a path to your client template compiler if you are using AMD because Mimosa almost entirely has that figured out via mimosa-require and via the fact that each template compiler comes with an AMD version of the client library.
If you imagine that you are building templates for the client, which is still Mimosa's chief use case (rather than the server development), then the require('handlebars')
still requiring a commonLibPath
makes more sense. require('handlebars')
just points me to where your server-side compiler is. It is what lets you very easily swap versions of the compiler.
commonLibPath
is still needed because for commonjs in the browser what the commonLibPath
needs to be is something like public/javascripts/vendor/handlebars/handlebars
. So require('handlebars')
and require('public/javascripts/vendor/handlebars/handlebars')
are obviously solving two entirely different problems.
On the first point, template config rolled up into template, I hear ya, and I suspect that if I had to do it over again I may head in a different direction, maybe moving more of the template config to each compiler, but it would be an epic and wide ranging fix. I'd have to address every template compiler, adding boilerplate to each for default config, validation, etc. And it plusses up the LOE for adding another template compiler down the road.
I'm trying to compile handlebars templates for use in a nodejs app.
The generated templates don't seem to reference the handlebars library properly -- I've tried with both an explicit config.handlebars.lib=require('handlebars') and with leaving the handlebars.lib value to default. Here is my mimosa-config:
This is the templates.js file produced -- require('null') on line 1?