Open ismay opened 8 years ago
Hi @ismay, thanks for reaching out. Glad you made an issue about this, not only about considering metalsmith-jstransformer
, but also about switching to jstransformers.
There are a few design considerations between how metalsmith-jstransformer
and metalsmith-layouts
/metalsmith-in-place
operate:
metalsmith-jstransformer
does both the in-place rendering, and layouts
metalsmith-jstransformer-layouts
together, but found benefits out of merging themmetalsmith-jstransformer-partials
is split into its own projectmetalsmith-jstransformer
renames all the files it processes on to what the acting JSTransformer outputs (i.e. uglify-js will output .js, while handlebars will output .html)metalsmith-in-place.opts.pattern
equivalent. metalsmith-jstransformer
just processes on all files. Made an issue for that: https://github.com/RobLoach/metalsmith-jstransformer/issues/10metalsmith-jstransformer
operate in the src/layouts
directory, as opposed to a directory outside Metalsmith source pathmetalsmith-jstransformer
allows running multiple JSTranformers on one file (ie main.js.uglify-js.babel
)Taking these into consideration, I see a few options going forwards and would love your ideas too:
metalsmith-in-place@2.x
and metalsmith-layouts@2.x
consolidate-jstransformer
and inform people to add the JSTranformer engines to their project with npm i jstransformer-handlebars --save
metalsmith-in-place@2.x
and metalsmith-layouts@2.x
use metalsmith-jstransformer
metalsmith-jstransformer
, affectively inheriting the pluginmetalsmith-in-place
informing people to switch over to metalsmith-jstransformer
metalsmith-templates
moved over to metalsmith-in-place
/metalsmith-layouts
I think taking option 1 for now is the easiest way forwards, at least for now. I'd love your thoughts! Where do you think we could go with this?
Apologies for the late reply. I think a variation of option 2 makes the most sense to me.
But instead of inheriting metalsmith-jstransformer I prefer implementing the jstransformer lib directly. That way we're just switching the engine that does the rendering and not depending on a different metalsmith plugin (in which case I'd say it would be better for people to just use that plugin directly).
I think it would be good to reconsider the layouts and in-place api, and see what we want to keep and what not. The separation between layouts and in-place is also something worth revisiting, but there'd have to be convincing arguments for merging them back together as the separation was the entire point of creating both those libs to begin with :).
So lots of work to be done :). Thanks for your feedback!
For metalsmith layouts and in-place we've been thinking about switching to jstransformer as our rendering engine: https://github.com/superwolff/metalsmith-layouts/issues/100. I personally like the modular approach and think it would be an improvement over consolidate. However, since this lib already exists it would maybe be a bit of a duplication of functionality.
We could switch to jstransformer for layouts and in-place and add you as a maintainer there, if you'd be open to that of course. Or maybe both libs have their own unique niche and it would make sense to develop them separately? What do you think?