Skip to content

Conversation

@mckelveygreg
Copy link
Contributor

Since the preview app is tucked away in node_modules, it doesn't allow for files to be served from a consumer's actual project root. This would help by serving local files (ex static/cat.png) during development

Component / Package Name:

This PR contains:

  • bugfix
  • feature
  • refactor
  • documentation
  • other

Are tests included?

  • yes (bugfixes and features will not be merged without tests)
  • no

Breaking Changes?

  • yes (breaking changes will not be merged unless absolutely necessary)
  • no

If yes, please include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.

List any relevant issue numbers:

Description

I'm really excited to use this repo! I made some contributions to the the OG react-email project, but it is time to update things, so I'm taking this out for a spin.

I really like the simplified dev env through vite, that seems much more intuitive to me as well. However, I'd like replicate some behavior that we built a bit of our CI tooling around: static asset handling.

react-email would do a very large and spooky copy/paste of assets in order to make them available during development. I'd like to keep the feature of using local assets in development.

Turning of vite's fs.strict field allows a dev to import (via import.meta.resolve) a local file that is outside of the vite preview project, which is nestled deep in node_modules.

Unless there is a more canonical why of doing this, check out my example I added to the docs for how it could work (and does with a monkey patch on my project).

(I'd like help with tests, I wasn't sure how to integrate using import.meta.resolve in the test file because the tsconfig module was not set to ESNext.
I tried with path and __dirname, but then also realized that it would resolve to the local machine, not the test env 😬 LMK!)

@shellscape
Copy link
Owner

shellscape commented Dec 20, 2023

Thanks for the PR! We're working on getting automated testing setup for the preview app (there's an in progress open PR for that). Because we don't have testing setup just yet, would you be willing to add a template to apps/demo/emails with an example that pulls in those resources in the way you're describing? Doesn't have to be anything fancy. We're eventually going to have playwright setup for some automated tests, but we can use that to test manually in the meantime.

…ce root

Since the preview app is tucked away in node_modules, it doesn't allow for files to be served from a consumer's actual project root. This would help by serving local files (ex static/cat.png) during development
@mckelveygreg mckelveygreg force-pushed the feature/preview/fs-strict-false branch from dbf2475 to 300a908 Compare December 20, 2023 18:39
@mckelveygreg
Copy link
Contributor Author

@shellscape Ok, I'd forgotten to push up a doc update last night! However, good idea for an email preview.

The demo app was giving me some type troubles... I don't like the tsconfig.json that I had to add, but it seems to make things happy again since vite isn't a direct dependency. 🤷

LMK if these updates are more in line with what you were thinking! Happy to contribute!

@shellscape shellscape changed the title feat(preview): allow preview server to serve files outside of workspace root feat(jsx-email): allow preview server to serve files outside of workspace root Dec 26, 2023
@shellscape
Copy link
Owner

Thanks for your patience and working with us on this one. The holiday threw some delay in there. I'm getting ready to merge this today so please keep an eye out for an update.

@shellscape shellscape changed the title feat(jsx-email): allow preview server to serve files outside of workspace root fix(jsx-email): allow preview server to serve files outside of workspace root Dec 26, 2023
@shellscape shellscape merged commit 5747cc4 into shellscape:main Dec 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants