[fix] Move preview-email to devDeps

[felixmosh]

Describe the bug

Since preview-email is for development purposes, there is no real good reason to make it a dependency of this lib. It should be defined as devDep, and required within the condition that enables it.

[titanism]

@felixmosh v12.0.0 of email-templates has been release to GitHub and npm with optional dependency of preview-email. In production environments it will console.error if you attempt to have previewEmail option with a truthy value, and in production environments it will throw.

Thank you for your feedback and patience @felixmosh

Consider supporting our efforts at https://forwardemail.net 🙏

https://github.com/forwardemail/email-templates/releases/tag/v12.0.0

[felixmosh]

I've tested the new version, with Yarn, looks like it still installs it :|

Since this lib only passes users config.preview to the lib, I think that it's better to make config.preview the lib itself, WDYT? Before

After

12 Mb of extra bloat

[titanism]

You may need to use yarn install --ignore-optional or yarn workspaces focus --production. Also note that NODE_ENV=production should prevent installing devDependencies. We do not use yarn.

[felixmosh]

Sure, my tests were with yarn workspaces focus --production

[titanism]

We suggest to use pnpm or figure out the underlying reason and submit a PR. We don't suggest to pass the function, it's an anti-pattern.

You already have 661M, and you're upset about 12MB extra? I think there are other things to be concerned about with time.

[felixmosh]

Yeah, that is right, but this is one of the big fishes :]

[titanism]

Don't you need to regenerate (delete/recreate) your lockfile completely after a big change like this?

https://github.com/yarnpkg/berry/issues/2425

[felixmosh]

I've tried it, no luck

What is the antipattern by passing the a function / the lib instance?