Possible to have multiple target build directories?

[connecteev]

I am just trying maizzle to see if it will save me time (moving over from mjml templates, I'm also a fan of tailwindcss).

One question I have is, is it possible to have multiple target build directories?

starter-litmus has templates for ceej and slate, and upon build, both get saved to different subfolders within the destination folder (build_local, for example). But can you specify different destination folders that are not within the same parent build_local?

Here's my use-case:

1. project_1 folder contains: unique header and footer, other unique email templates
2. project_2 folder contains: unique header and footer, other unique email templates
3. common folder contains: common components (to both projects)

I have all files in

• template files in maizzle/src/templates/project_1 and maizzle/src/templates/project_2
• component files (header and footer) in maizzle/src/components/project_1, maizzle/src/components/project_2 and maizzle/src/components/common

I would like my compiled / built email templates to go into ~/home/project_1/emails and ~/home/project_2/emails

Is this possible with the config?

[cossssmin]

While it's not possible to define multiple build destinations in Maizzle, you can simply structure your emails inside the base templates folder - maybe like this in your case:

- src/templates/project_1/emails
- src/templates/project_2/emails

Use the templates.root default setting (src/templates) and set the build destination to your home directory:

destination: {
  path: '~/home', // or just 'home', not sure, I don't use a Mac 🤷‍♂️
},

Maizzle will copy all files from src/templates to that destination while preserving directory structure (careful how you name your folders, build destination directory is deleted before copying).

Another way of doing it is to use the permalink key for each template.

[connecteev]

@cossssmin Thanks for the tips. I didnt know about the permalink key for each template....but it's not quite what I'm trying to do, since the permalink frontmatter doesn't let me add global variables (right now, I cannot have multiple templates, especially as they grow to 40-50, to use the same root permalink).

Can I suggest that we try to have multiple build directories (original suggestion)? It could be very similar to what you've done for assets

If you've structured your emails inside the base templates folder, say like this:

• src/templates/project_1/emails
• src/templates/project_2/emails

The config would change from:

destination: {
  path: 'build_local',
},

To something like this:

destinations: {
  [
   source: 'src/templates',
   destination: 'buid_local',
  ],
  [
   source: 'src/templates/project_1',
   destination: 'C:/Users/Cosmin/project_1',
  ],
  [
   source: 'src/templates/project_2',
   destination: 'C:/Users/Cosmin/project_2',
  ],
},

All files within src/templates/project_1' will get built in C:/Users/Cosmin/project_1 All stray files within src/templates (that are not within the other source specified, like 'src/templates/project_1', 'src/templates/project_3') will get built in buid_local.

so you could have multiple destinations or target build directories..

For simple use-cases you'd just do:

destinations: {
  [
   source: 'src/templates',
   destination: 'buid_local',
  ],
},

[cossssmin]

Sounds good and I’m all for it, but:

1. destination. Plural is a breaking change.
2. Simple use case would not use an array, it would just be as it is today.

I’ll start playing around with this for the next feature release, thanks!

[cossssmin]

Actually just re-read and it would be breaking nonetheless. Will have to think about structuring it, but if we do it will most likely have to be in v2.0

[connecteev]

@cossssmin How about this to prevent a breaking change:

Default stays the same for simple use-cases:

destination: {
  path: 'build_local',
},

For multiple target builds, something like this (optional, would be added in addition to the destination config). It would be almost identical to the assets config.

destinations: {
  [
   source: 'src/templates/project_1',
   destination: 'C:/Users/Cosmin/project_1',
  ],
  [
   source: 'src/templates/project_2',
   destination: 'C:/Users/Cosmin/project_2',
  ],
},

[cossssmin]

It would still be a breaking change, we’re defining template sources elsewhere now. And it also confusing to have such similar key names, I wouldn’t want it like that tbh. I’ll think about it though, as it’s an useful feature to have.

[connecteev]

That makes sense...look forward to using this as soon as it becomes available.

[cossssmin]

We could probably get rid of build.destination and use something like this:

module.exports = {
  build: {
    templates: [
      {
        root: 'src/templates/project-1',
        filetypes: 'html',
        destination: {
          path: 'build_local',
          extension: 'html'
        },
      },
      {
        root: 'src/templates/project-2',
        filetypes: 'html',
        destination: {
          path: '~/project-2/mailables',
          extension: 'blade.php'
        },
      }
    ],
  }
}

A single source would then look like this:

module.exports = {
  build: {
    templates: {
      root: 'src/templates/project-1',
      filetypes: 'html',
      destination: {
        path: 'build_local',
        extension: 'html'
      },
    }
  }
}

I've also renamed extensions to filetypes in the examples above (it used to be named like that previously), so that it doesn't create confusion with extension, now that they'd be added under the same key.

[connecteev]

This config is very intuitive to me.

For single source, I imagine you could still do root: 'src/templates' (without requiring files to be in a subfolder like root: 'src/templates/project-1') - this would make it easier for people that dont have a complex config.

I've also renamed extensions to filetypes in the examples above (it used to be named like that previously), so that it doesn't create confusion with extension, now that they'd be added under the same key.

Makes sense to me.

[connecteev]

This is a nitpick so feel free to reject this idea, but maybe 'source' instead of 'root' is more intuitive and pairs nicer with "destination".

[cossssmin]

this would make it easier for people that dont have a complex config

Yes of course.

This is a nitpick so feel free to reject this idea, but maybe 'source' instead of 'root' is more intuitive and pairs nicer with "destination".

You're probably right, it'll be a breaking change anyway...

[connecteev]

thanks for the consideration. Look forward to using this.

[cossssmin]

Added in 4400f93. Required workarounds for unexpected issues, like Browsersync compatibility, but it should be good now. Will be part of v2.0 next month if it doesn't break anything else 😂

[connecteev]

@cossssmin awesome, thank you. And your timing could not be better.....just hope it can be checked into the master / release branch because i'm putting other features on hold to re-explore maizzle this weekend.

[connecteev]

can we merge this baby in? can't wait to use it ♡

[cossssmin]

Going to merge soon, taking care of a few extra touches. If you have any feedback on the implementation, please add it to https://github.com/maizzle/framework/pull/291, thanks!

[cossssmin]

@connecteev v2.0.0 is live, see #291 for details and update to give it a spin 👍

[connecteev]

@cossssmin exciting..thank you!👍
I'm going to give this a a spin very soon (this week most likely). I'll have some feedback for you soon on how it goes!

[connecteev]

@cossssmin I spent some time re-familiarizing myself with maizzle (it had been a few months) - this works great right out of the box, and is highly flexible + configurable. 👍

I'll start a thread on this, but I am struggling with passing variables into components, not sure if it's user-error or a regression.

[cossssmin]

Sure thing, thanks! Do also check the docs for that in case you haven’t already:

https://maizzle.com/docs/components/#variables

[connecteev]

@cossssmin thank you, I got the variable-passing to work (I previously had the "brilliant" idea of using <!--- and --> to wrap the frontmatter, because I was trying to remove the preheader. I could have just removed the preheader instead, the <!-- comments were breaking the variable passing (no surprise there).