Closed joegaudet closed 9 years ago
app/pages.index.us
with a <%= pkg.version %>
, that'll do.lineman config foo
). If it's boilerplate code, then the framework failed. If it's entire app skeletons, then the day one complexity is too high. Saddling anyone with code they don't understand with no upgrade path is always a bad idea in the long-term.It may be worth noting lineman supports versioned assets and a simple manifest as of this release: https://github.com/linemanjs/lineman/releases/tag/0.24.0
enableAssetFingerprint: true
is all you need to add in config/application.{js,coffee}
and you'll see an md5 hash and manifest generated on lineman build
.
Hey Guys,
As always love the work you've done on lineman, makes our lives so much better.
I have a few questions about best practices and features.
1) Shared Libraries, currently we have a shared library for our angular app (a bunch of shared directives / css etc), and its included as a git submodule. I was wondering if you guys have any better approaches, publishing a private bower module and including it that way? Ultimately we'd like to have it run through its own git flow based release cycle, but this also seems to slow down development some. Any thoughts?
2) Version numbers, is there a lineman-ey way to get the package.json version number in inside the JS / html ?
3) Code Generators, is there a plugin already in mind for this sort of thing? I see Yeoman has some sort of structure for this, any thoughts around this?