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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: react-app-rewired #33

Open
manuphatak opened this issue Sep 17, 2018 · 1 comment
Open

Discussion: react-app-rewired #33

manuphatak opened this issue Sep 17, 2018 · 1 comment

Comments

@manuphatak
Copy link

Curious if y'all have been following timarney/react-app-rewired? This group found a different approach to extend CRA without ejecting or forking. Interested in your thoughts and experience.

  • Does this look like a maintainable approach to extending CRA? Do you see any big red flags?
  • Have you considered creating a set of "zeal-rewired" packages? Compared to forking, would this be a simpler mechanism to extend CRA for both you AND users like myself?

My interest. I'm reluctant to eject: CRA does a lot of great things for us! However, I'd love the chance to explore different ideas; for example, disabling code splitting on our dev env for quicker builds OR being able to generate build stats for analysis.

@randycoulman
Copy link

randycoulman commented Sep 17, 2018

I've done some experimenting with it. I was able to replace most of what we do in this fork with react-app-rewired, but I was not able to replace the parts of this fork that deal with paths.

This fork puts all of the front-end code into a client directory rather than src and also allows the build directory to be configured. Last time I looked, react-app-rewired was not able to do those two pieces.

There are a couple of other pieces I haven't fully tested in my experiment, but I don't expect an issue with those.

One of the ideas we've talked about is having our own "rewire" configuration that would use the standard CRA paths. We'd then modify this fork to pull in that configuration and add the path parts of top of that for projects that needed the new pathnames. We haven't had time to spend on any of this stuff lately, though, so no promises on when (or even if) that will ever happen.

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