chore: migrate to monorepo - Githubissues

formspree / formspree-js

The fastest way to hook up a React form

https://formspree.io/javascript

MIT License

63 stars 12 forks source link

chore: migrate to monorepo #14

Closed smakosh closed 2 years ago

smakosh commented 2 years ago

What's new?

Migrate to monorepo using Turborepo and yarn workspaces
Add more examples
Migrate away from Rollup to tsup

To test

TBD

vercel[bot] commented 2 years ago

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
formspree-react-demo	✅ Ready (Inspect)	Visit Preview	Sep 6, 2022 at 0:10AM (UTC)

colevscode commented 2 years ago

Note: I've republished version 2.3.0 as 2.3.2 and then fixed additional dependency issues in 2.3.3. Please do not re-publish this branch to NPM. NPM packages should only be published from the main branch after merge.

colevscode commented 2 years ago

Some general confusion with this repo. Initially I went to the root and ran:

yarn install
yarn run dev

which caused a lot of errors. Do I need to run yarn run build first before running dev? If so please document, otherwise if not, there is a problem with the dev script?

colevscode commented 2 years ago

Still trying to grok the monorepo workflow. I think the ideal scenario is, lets say I want to add a feature to @formspree/react:

checkout the latest copy of the monorepo, run yarn install from the root
go to an example project, run yarn run dev
now switch to the formspree-react package. Begin making changes.
updates to formspree-react should be reflected immediately in the example project.
When I'm ready, submit PR and get reviewed.
Later, once my changes are merged, I can pull them, and then run yarn run release from the formspree-react folder

This assumes that the graph of dependencies created by turborepo is visible from all project folders (ie when I run yarn run dev from an example project, it builds and links in the local dependencies such as formspree-react). Is that true?

This also assumes changes to local dependencies will be watched and trigger builds in other packages or projects. Is that true?

Finally this assumes I can run a release command in a single package folder, and it will also release any relevant dependencies (after prompting to ensure it's OK). Is that possible?

colevscode commented 2 years ago

I think the examples are primarily for development and secondarily for demoing features. I think for now we should pick a bundler and stick to it for all our examples. I don't think we need CRA and Vite. We should pick one that we want to use during development and testing. My vote is for Vite, and removing CRA.

I also think we should split up the example into a basic, and form examples. There will likely be other examples, such as for file upload, recaptcha and other situations. We should guide what examples to include based on what functionality / features we need to build / test.

I don't think our examples in this repo need to be an exhaustive set of all features or bundlers that we want to demo/showcase. I still think we are debating wether this repo is the right place for all our example content. My feeling is that, given how many example projects we need, and that they need to work in various environments / workflows, it's unreasonable to expect that they can all live in the main monorepo. I would consider having a second repo with just examples, however we still need to figure out if each example in such a repo could be forked indpendently / deployed to vercel and netlify and possibly other platforms.

colevscode commented 2 years ago

It should be as easy as possible to clone the repo and get the examples working. For that reason, all env vars should have reasonable defaults. If the form hashids or stripePKs aren't supplied, the project should still render instead of today the page is blank due to errors from missing env vars.

colevscode commented 2 years ago

TODO

[ ] remove CRA
[ ] split up Vite example into basic and stripe examples
[ ] introduce fallback values for all env vars so that at least the page renders. For example instead of const [status, submitHandler] = useForm(process.env.FORM_ID) which will cause a render error, lets try something like const [status, submitHandler] = useForm(process.env.FORM_ID || "FORM_ID_NOT_CONFIGURED") This code will still render, however when the form is submitted there will be a form not found error and the console will show an API request to https://formspree.io/f/FORM_ID_NOT_CONFIGURED which helps diagnose the problem.

smakosh commented 2 years ago

Still trying to grok the monorepo workflow. I think the ideal scenario is, lets say I want to add a feature to @formspree/react:

checkout the latest copy of the monorepo, run yarn install from the root

go to an example project, run yarn run dev

now switch to the formspree-react package. Begin making changes.

updates to formspree-react should be reflected immediately in the example project.

When I'm ready, submit PR and get reviewed.

Later, once my changes are merged, I can pull them, and then run yarn run release from the formspree-react folder

This assumes that the graph of dependencies created by turborepo is visible from all project folders (ie when I run yarn run dev from an example project, it builds and links in the local dependencies such as formspree-react). Is that true?

This also assumes changes to local dependencies will be watched and trigger builds in other packages or projects. Is that true?

Finally this assumes I can run a release command in a single package folder, and it will also release any relevant dependencies (after prompting to ensure it's OK). Is that possible?

This is not how it should be used.

Running just yarn dev from the root will run everything in parallel.