jsonresume / jsonresume.org

The mono repo that builds the homepage, utils, ui components, registry and anything else
https://jsonresume.org
68 stars 18 forks source link

configure remote caching #15

Closed levino closed 9 months ago

levino commented 9 months ago

I personally think turbo build is a bit overkill for this project. However it is fun to play with it, so I am grateful for its usage here. I would configure remote caching via vercel though, in order to really get the advantages turbo build promises.

thomasdavis commented 9 months ago

@levino I've recently really learned to love the turbo/vercel setup, everything just works, and cheap as chips.

To try communicate the full vision in my mind, the mono repo will;

pnpm publish

Everything under the @packages name space will be published (if updated) to npm under the @jsonresume namespace.

Keeping a schema and ecosystem together is quite an arduous task, I think the tooling behind turbo repo makes a monorepo achievable (in the past when approaching separation of concerns I'd make a repo for everything)

Inside of this monorepo, besides the apps, the packages folder will serve to make things easier for all of the ecosystem, e.g;

@jsonresume/utils/dates 
@jsonresume/converters/json-yaml
@jsonresume/themes/json-to-latex 

Not great examples (running out of time tonight sorry)

@levino send me your vercel username and I will add you to the project.

(I will try update this comment tomorrow)

levino commented 9 months ago

I see. However I am pretty sure you can achieve this kind of synchronized publication as well with yarn workspaces or lerna. As far as I understand the benefit of turbo as with nx is about reducing build times (and all other ci jobs) for large (large!) monorepos. You simply skip a lot of unnecessary build jobs, if things are correctly configured. Really enjoyed the fireship video about turbo (and a bit about nx).

If you are planning for easy publication etc., you should have a look at release please which I use for mock-jwks.

Also a friendly advice: Only create new (sub-)packages, when it is necessary. Meaning: When you use it in at least two places. I have seen a lot of projects, where it looks like things have been distributed over hundreds of tiny packages, just for the fun of it while creating a lot of complexity for kinda no reason. It is tempting to "create order", but often unnecessary.

levino commented 9 months ago

And back to the topic: We need a VERCEL_TEAM variable and a VERCEL_TOKEN secret for the github actions, then I can speed up the ci scripts with remote caching. So far, I do not have access to these github settings.

levino commented 9 months ago

Done in #18