layouts and in-place

[ismay]

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?

[RobLoach]

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.

Design Changes

There are a few design considerations between how metalsmith-jstransformer and metalsmith-layouts/metalsmith-in-place operate:

1. metalsmith-jstransformer does both the in-place rendering, and layouts
   • I had originally put metalsmith-jstransformer-layouts together, but found benefits out of merging them
2. metalsmith-jstransformer-partials is split into its own project
3. metalsmith-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)
4. There is currently no 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/10
5. The layouts in metalsmith-jstransformer operate in the src/layouts directory, as opposed to a directory outside Metalsmith source path
6. metalsmith-jstransformer allows running multiple JSTranformers on one file (ie main.js.uglify-js.babel)

Moving Forwards

Taking these into consideration, I see a few options going forwards and would love your ideas too:

1. Simply replace Consolidate.js with JSTransformer in metalsmith-in-place@2.x and metalsmith-layouts@2.x
   • Easiest way would be to use consolidate-jstransformer and inform people to add the JSTranformer engines to their project with npm i jstransformer-handlebars --save
   • You'd be missing out on some of the additional features this project provides
2. Make metalsmith-in-place@2.x and metalsmith-layouts@2.x use metalsmith-jstransformer
   • Adapt the options and push them over to metalsmith-jstransformer, affectively inheriting the plugin
3. Add an install notice to metalsmith-in-place informing people to switch over to metalsmith-jstransformer
   • Similar to how 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?

[ismay]

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!