Roadmap Discussion

[StrikeForceZero]

I'll fill this out more later, just creating a "placeholder" issue to discuss the roadmap for this fork.

As a preface I will say this is one of, if not my most passionate forks I've worked on and intend to actively support it as long as I use it myself.

---

I've had some thoughts over the past few months on the intended direction I wanted to take this fork. In a sad reality to OSS, and as much as I want it to, I don't think its in the projects best interest to stay attached to upstream (from my perspective merging in files that are of a different extension then going through and performing diff patches manually, will just pollute the history ☹️ )

If someone was ambitious enough to write some form of script to do this automatically and rebase each commit as the original author? Then someone can come in and added type definitions when needed. That could help keep the history clean if we ever pulled from upstream. To be honest, I'm not intimate enough with git to know if there is a way to even pull this off. A perfect world would still maintain references to their parent commits in such a fashion that they aren't pulled in a second time. I have googled briefly and see there is a local solution using the resolve cache, but that's as far as I got.

Hopefully this explains to any watching this project, why I cleared all the preexisting tags and started back at v0.1.0 (In my head that means "it works" but don't expect it to be perfect jumping to v0.2.0 until we near 1.0 when semver will feel more natural. I usually feel more responsibly inclined, instead of just packing on as I go.

---

Goals

• prefer any solutions that will integrate well with IDE's (I use intellij/webstorm full time, I know there are atom/vscode users out there)

  • example: intellij has a quick run for mocha unit tests built in
    (not yet working with this fork, no way to register tsconfig-paths runtime when intellij boots up ts-node. Some trickery with jsdom may also be needed)
    

• from my example above, optionally test between karma / jest / mocha. I didn't dig into this too much, but I'm unaware of why upstream fully dropped karma. I am enjoying my first experiences with jest but it would be cool to have both options.

• I'm not proud of the polluted git history. I'd love to rebase it all and clean it up.

  • For the sake of not breaking anyone tracking it, but not watching the project, I've left it alone.
  • Including the no longer updated typescript branch that was originally intended to house all the porting work I was doing when I first made this fork.

Extended branches/features

Personally, I dislike boilerplates that are over stuffed, but then at the same time, I steer away from ones that lack options, or examples, even more.

Some of the branches I've had interest in but are not limited to:

• maintan a port of upstream for simple typescript lovers
• maintain a near "zero examples" branch? (https://github.com/StrikeForceZero/react-typescript-boilerplate/tree/feature/barebones)
  • porting the internals folder and all the templates to typescript then running clean script might be a more sane approach.
• sass/scss
• react-md (currently my favorite material themed component library)
  • material-ui (I dislike their inline styles and use of pixels for everything)
  • react-mdl (requires a few hacks on componentDidMount to fix some components like tabs)
• moment/moment-timezone this hack took a few hours to figure out
• isomorphic highcharts - I've done this in the past with the repo, would love to have it easily pulled in on demand
• flexbox-attributes - goes against per component styling, and adds extra attributes, but is super handy when you are in a hurry. styles, hand made type definitions, more info

It's neat and helpful IMO to see how all the different packages / technologies can bee tied together and really makes the boilerplate more useful when these are readily available to give someone a headstart.

---

May add more as I get time.

[opavader]

I recently started using redux-little-router instead of react-router. Its has much cleaner design & integrates extremely well with redux-saga. Something you can consider.