Open arjunyel opened 4 days ago
the inline, minify, and pretty plugins are considered "core" and are peerDependencies, which most package managers will install automatically these days. So there's really no need to pass them in. I think this is a case where we need to see a reproduction and treat it like a bug, however. esbuild, webpack, rollup, etc should pick up on dynamic imports and include the package contents. We're dynamically importing the plugins here: https://github.com/shellscape/jsx-email/blob/7e9406520e5c667d935e475d57e3501c6e2e316f/packages/jsx-email/src/config.ts#L111
Should esbuild not be including the package, try changing that line in /dist
in node_modules
for the package, to use @jsx-email/plugin-inline
instead of plugins.inline
and see if that resolves the missing module exception. (Or you can whip up a reproduction in Stackblitz and I'll be happy to do that for you)
Feature Use Case
I am using jsx-email in an AWS Lambda function via https://sst.dev/ which uses Esbuild under the hood.
I am having some trouble bundling the plugins properly, for example in my logs I have:
jsx-email: Tried to import a plugin '@jsx-email/plugin-inline' but it wasn't found
Feature Proposal
To be the most bundler friendly I think it would work if one of the render function options was a plugin array where I could pass in the plugins directly. That way Esbuild wouldn't tree shake the plugins out.
Thank you for the excellent work!