Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

The problem with maintainability #171

Closed
sabarnix opened this issue May 10, 2022 · 6 comments
Closed

The problem with maintainability #171

sabarnix opened this issue May 10, 2022 · 6 comments

Comments

@sabarnix
Copy link

馃檹 Thank you for this awesome React boilerplate 馃檹
Is your feature request related to a problem? Please describe.
There was a problem of maintaining (keeping track of the boilerplate changes) the project created with react-boilerplate, which was fixed to some extent by moving it to cra-template. Now, webpack and babel configs can be updated just by updating the react-script package.

For the rest of the configurations and generators, it is still difficult to update them by checking the changelog and diff.

Describe the solution you'd like
Move the project to a mono repo. Create separate packages for the generators, utils and configs (ESLINT, PREETIER etc). It will be very easy to upgrade to a new version of boilerplate this way.

Describe alternatives you've considered

Additional context

@Can-Sahin
Copy link
Member

I dont follow much. Utils and App folders are tightly coupled. There was never a case you need to modify just one without touching other. What good would it do to make them separate packages? Configs and lint prettier etc they hardly ever change anyway.

It can be never easy to just 'upgrade' to new version, sorry I have given lot of thoughts about it and still no good trade-off.

A monorepo would be way harder to maintain and keep it simple.

@sabarnix
Copy link
Author

I will try to share a PR by this week

@react-boilerplate react-boilerplate deleted a comment from Wasoop May 24, 2022
@sabarnix
Copy link
Author

@Can-Sahin this is still WIP. https://github.com/sabarnix/react-boilerplate-cra-template/tree/wip. See if you like the idea.

@Can-Sahin
Copy link
Member

thanks will check it out.

@Can-Sahin
Copy link
Member

Ok I checked it and its pretty much what I imagined at first. But still struggling to understand how helpful would this be?

  • dotfiles folder almost NEVER change. The last change was probably 2 years ago.
  • internals file will be updated mostly 80% of the time when template folder is updated. Starting templates and generators are directly targeting the real app so its highly coupled. Meaning, almost all the releases will have 2 release with first template package and then internals package.

This monorepo would only come handy when doing version bumps for template package because you cant just bump the version of react there and dont touch other packages.

I like the idea actually but I feel like the components of the boilerplate is all together single unit of work. There are not really independent pieces isolated from others. I have several future plans like switching to redux toolkit query and ditching redux-saga etc but considering those with this monorepo approach I have to 3 releases (each package) and it would even complicate things for everybody willing to update

@sabarnix
Copy link
Author

sabarnix commented May 31, 2022

After doing some more research I found that, since react-boilerplate is tied to cra, the current implementation is probably the best suited for most uses.

In my case, I maintain a lot of apps created form the react-boilerplate which has some modifications like some uses rtk-query, some only redux and few uses typescript. My goal is to maintain the dotfiles for all projects in a repo and have different versions of generators. I will continue to work on the fork for my projects. I am also exploring razzle which might be better suited for my need. Will work on creating a react-boilerplate like setup for razzle.

regarding switching to redux toolkit query, it is great but only when your project is simple fetch and show data. When things gets complicated I feel the code becomes more complex as you have to do more in transform response to store in normalised form. For which I think it is better to use just the redux toolkit.

@Can-Sahin Can-Sahin closed this as not planned Won't fix, can't repro, duplicate, stale Aug 2, 2022
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

No branches or pull requests

2 participants