split mjml and mjml-cli - my team only consume mjml2html function from mjml package and does not use cli which adds a lot of dependencies
I'm not sure about this one, mjml package should remain the default package to have the full experience, you can still just target core + every other dependencies manually and register components manually here ?
move html-minifier and js-beautify to cli
May be we should move that part on its own package and let user requires it with .mjmlconfig ?
Sure, any option would be good
After separating mjml-cli (with minifier and beatuifier) it should be much easier to support browser targets, which I kindly ask to add for v5 roadmap. In-browser email builders with bundled mjml (instead of using API) are a perfect use-case for that.
Is this why there's both mjml and mjml-cli on npm?
https://www.npmjs.com/package/mjml
https://www.npmjs.com/package/mjml-cli
That really confused me when I went looking to install it and saw references to "the cli".
They have different dependencies, but the readme for the mjml-cli npm package seems to just be a different version of the readme for mjml. It uses mjml throughout, instead of mjml-cli (including for the installation!) -- but if you have mjml-cli you'd have to run things like mjml-cli input.mjml, not mjml input.mjml, right?
Or is the npm mjml-cli package just a placeholder for now?
Forgot to reply @rootwork mjml is the "community" package where everything is setup to have the standard lib working (bundling the cli + std components). mjml package have an extra binary that register every components before passing everything to mjml-cli.
mjml-cli rely on mjml-core but not on mjml package.
Most helpful comment
After separating mjml-cli (with minifier and beatuifier) it should be much easier to support browser targets, which I kindly ask to add for v5 roadmap. In-browser email builders with bundled mjml (instead of using API) are a perfect use-case for that.