Extracting scripts to improve maintainability of descendent projects

[paulmelnikow]

Hi! Thanks so much for this useful tool. 🌟

What would you think about extracting some of the boilerplate code into a package, react-scripts-style? Then users could eject if they have something too custom they want to do.

My use case is for React packages which are occasionally touched. It would be ideal if I didn't have to manage quite so many dependency upgrades on each one, so the time spent is more focused on the code itself and less on the surrounding tooling.

I appreciate the traction this tool has and might be interested in helping with this.

[transitive-bullshit]

Thanks @paulmelnikow -- this is definitely a great suggestion.

I just commented with some related thoughts on #103. Would love to hear what you think.

The main issue is that supporting "eject" is kind of difficult to implement on our side, though I agree it's probably what most people would want.

[sag1v]

The main issue is that supporting "eject" is kind of difficult to implement on our side, though I agree it's probably what most people would want.

Supporting eject is a must in my opinion, most library authors who will use this CLI will probably be familiar with create-react-app / react-scripts and will assume there's an escape hatch like eject.

I think that in-lining with create-react-app's design and architecture is the most natural thing to do, but i also think once we go this route we will need to keep up with changes of CRA to keep it in sync.

[paulmelnikow]

I imagine many of the use cases for CRL are small libraries. Eject is handy when a library needs to do something very different, though it's also quite extreme. Many authors would prefer to override what needs to be overridden without ejecting. Since this project is much less complicated than CRA, maybe it would be feasible to do that.

Getting rollup working for the first time takes a very long time, and I agree an abstraction over rollup and babel is pretty essential. In #103 you mentioned microbundle. They're still using Bublé, and the Babel support is stalled. Babel support seems essential to adopting it.

Alternatively the scripts package we're discussing could contain the abstraction, and we could reconsider microbundle down the line.

[paulmelnikow]

What would be a good way to get started? Would it make sense to mock up an initial version of the scripts?

I think that in-lining with create-react-app's design and architecture is the most natural thing to do, but i also think once we go this route we will need to keep up with changes of CRA to keep it in sync.

Is there some history written about CRA's no-configuration philosophy? My experience with CRA has been on the consuming side. I've had some good experiences, though also ran into issues trying to configure it. For me the blocker was TypeScript, but of course CRA 2.0 has TypeScript support.

Here's a post-2.0 wishlist from react-app-rewired: timarney/react-app-rewired#162 (comment). There's also the config schema for craco. We could consider those as starting points for what developers might want to configure.

As a software engineer, I find boilerplate problematic. I picked this up at the last startup I was at, where one developer would always ram this point home. When boilerplate gets copied from project to project, it becomes difficult to maintain. Issues are found in one project and fixed, but the fix isn't ported to the boilerplate, let alone other projects. Every project starts to behave differently, but subtly so, and in ways which usually are not documented. Tasks which should be simple, like adding tests to a library, turn into involved projects.

I think the goal should be to minimize the amount of boilerplate. Judicious customizability combined with good release documentation is the best way to accomplish that.

I'd go so far as to argue that customization of the important bits is more important than an automatic escape hatch.

[transitive-bullshit]

@paulmelnikow definitely on the same page w.r.t. motivations.

I had previously considered adding eject functionality about 6 months ago, but nobody was really interested in it at the time.

As a good first step, I suggest we create a react-library-scripts package (name currently squatted) which would contain:

• eslint, babel, and rollup deps
• related linting, transpiling, and bundling logic

I think being able to override eslintrc, babelrc, and the rollup config should be plenty for a first version of this.

I do, however, think that the ability to eject is much more important for library authors who are more advanced & hands on than your average app author. In any case, let's KISS and get a version of these scripts packaged to see what that would look like and we can always add the ability to eject afterwards.

This would be a large, breaking change for Create React Library v2, but one that I'm really excited about!

@paulmelnikow @sag1v if you'd like to chat about next steps and/or become maintainers, please let me know and we'll schedule a call.

Thanks!

[sag1v]

@transitive-bullshit sounds good 👍

[paulmelnikow]

Yea, let’s connect!

[pgarciacamou]

As a regular consumer of this great library, I believe making this repo a zero-configuration library is an excellent idea and so far looks underappreciated (not enough love in this issue).

I would love to see a roadmap to check if there is anything I could contribute, and I'm sure other developers might like to pitch in as well. If there is no roadmap, there surely are dozens of experts in building no-configuration libraries somewhere (not me) and could help to build the roadmap as well 🤞.

[transitive-bullshit]

This should be fixed now with the latest v3 release as we've switched to using microbundle for the core scripts.