Guidance for downstream forks?
lsanders opened this issue · comments
Is your feature request related to a problem? Please describe.
Hi, first, thanks for this awesome fork! I'm considering forking this to add support for micro-frontends and serverless aws deployment and I guess I'm looking for some guidance. It looks like you are intending to pull in changes from the RBP upstream as they release, which appears to be a fair amount of work! Do you expect you'll continue?
I just did a dry run from master/dev and it did not go as well as I had hoped!
Describe the solution you'd like
Do you think we'd benefit from some type of quick guide to pulling upstream changes in? Do you have any automation or tricks to help work through the js->ts renames and conflicts?
Describe alternatives you've considered
I'm considering tracking the upstream directly but I'm not sure I'm skilled enough ;)
Additional context
Again, just much thanks for the fork!
Synching with upstream is always a problem for me. Since TS JS are different alot. So far I manually carried it out with every master.
Merge master into my master -> fix everything(which takes work) -> commit my master. And i am only merging to keep myself synched with the upstream master.
Original boilerplate is waiting for styled components 5.0 release for releasing the version 4.1. I needed the version 4.1 with hooks so I did it earlier than them. Now actually I am ahead of the upstream master. I already put lot of upstream/dev into my master currently.
Now comes the important news
Original boilerplate will be switching (most-likely) to typescript as we discussed in a pull request in the version 5.0. So my merging mess gonna end. There will be one repo. You can wait till it happens if you want.
Or... you can merge into my fork. I am keeping it updated. My projects also depend on this. So will not abandon this.
I have no suggestions for merging upstreams unfortunately.
Speaking of serverless
My job isnt even React. I am AWS Developer focused on serverless. I dont think serverless deployments and stacks are so necessary for this boilerplate since Cloudfront Distributions are very console easy and AWS Stacks are highly configure -dependent things. Like iam policies and profiles, frameworks etc.
I will be doing a serverless pre-rendering repo for SEO sometime soon. So gonna introduce serverless into this repository anyway.
Thanks for the info - I didn't know there was typscript talk in RBP again, that's awesome.
Yeah, I agree, serverless (and specifically serverless.com) aren't necessary but it fits with the rest of our stack.
@Can-Sahin Sorry to have to ask you this, but I can't find the thread that discusses moving RBP to typescript (only the original threads about your fork). Can you give me a pointer?