How I decided to revive my project that was stale for 5 years... Part 2

Intro

In the first part of the series, I put together a fairly universal checklist on how to decide which projects to keep active in your GitHub profile. In this chapter, I will show how that list can work in practice, using one of my older projects: typescript-react-function-component-props-handler.

I initially thought I would publish this chapter much sooner, but it turns out that getting the context and scope right for this series of articles takes a bit of time - and that is perfectly fine.

This is Part 2 of the series, where I will be focusing on measuring the impact of a project I shared previously.

Before diving into any research, let's briefly recap what exactly this project was doing five years ago.

What the project does

typescript-react-function-component-props-handler is a custom React function component props handler for react-docgen version 5.x.x. It allows you to parse props (prop types) that are typed as React.FunctionComponent<Props> without having to rewrite your components.

Back in 2020, the main aim was to help frontend developers follow what was then a common way of defining props in TypeScript and React.

It was interesting that initially the as React function components were defined as functions, so utilizing definitions of typical functions with paramaters definition was common in different codebases, such as:

const Button = (props: propsType) => ...

And everything works perfectly. However, with more and more teams starting to utilise this approach for new applications and codebases:

const Button: React.FunctionComponent<Props> (props) => ...

So it seemed to be reasonable to have a support for parsing such option by react-docgen.

For that purpose the package acts as a custom plugin (handler) for the react-docgen parse function. It allows to support all previous existing notations and new React.FC<Props> ones. And that I built in 2020.

The question now is: can this package still do that job effectively in 2025 or 2026? Let's try to figure this out.

Measuring the impact

Back in the day

Trying to measure the impact of a project, especially five years after you last worked on it, is quite an interesting exercise.

Let's start from the very beginning.

For this project, it all started with researching the original problem and potential solutions, which led me to this issue reported in react-docgen:

The issue had around 156 reactions, which suggests there was a decent amount of interest. The problem also affected Storybook 5.

So it's fair to say that, back in 2020, the tool was genuinely able to help to solve a real problem for frontend developers.

But what about 2025 or 2026?

The first step now is to understand how newer versions of react-docgen handle React function components and TypeScript prop definitions.

Starting from react-docgen 6+, the interface of the parse function changed. It now uses the Babel toolchain to process TypeScript types for the ASTs.

In theory, this should be faster and it would be good to compare the different version performance in practice. That could easily become a separate direction for exploration.

Nevertheless, there was also react-docgen-typescript tool in 2020.

I am also curious about how the performance of react-docgen-typescript has changed since then - especially given how many projects are now using different software to generate bundles, such as Vite (and Webpack 5...). Back then, one of the main constraints was that running Webpack with react-docgen-typescript on repositories with 1,000+ components could take ages. Things may well have improved by now.

Going back to react-docgen, I saw there's an announcement about the future of TypeScript support in react-docgen here:

With that in mind, it might be worth exploring how much effort it would take to keep good support for React function component props in TypeScript for new version of react-docgen going forward. That could become a completely separate topic and a longer-term direction for this project.

And this is quite an important point: you really do need to take the time to understand the current landscape properly. Exploring a scope that is even slightly ambiguous (or ambitious, if you prefer!) can take some good time.

Scope definition

So, let's set some clear boundaries and define the scope for version 1.x.x of the project. The toolchain and environment will be:

• react-docgen 5.x.x, which is the most important limitation for now.

Other dependencies that can be tested and documented for compatibility in the new versions:

• React 17+
• TypeScript or even just the prop-types module (as noted for Storybook 5.2.1+ in https://github.com/storybookjs/storybook/issues/8279), which means the custom handler can also help with prop definitions for certain Storybook versions.
• Node 12+ (to be confirmed)

My initial plan was to provide examples in the project's GitHub repository showing how to assess the existing tools and ecosystem under these constraints. For that, I will need to pick some still supported projects to use as a reference points.

The best way to start is by finding out which projects are still using react-docgen 5.x and might benefit from enhanced prop generation - things like component libraries, parsing tools, SaaS products, and so on.

Thankfully, these days it is relatively easy to find open data about open source projects: npm stats, GitHub search results, and similar sources are all readily available.

NPM stats

As I mentioned earlier, it's useful to see which projects use or depend on your package. I started with a simple question: how many projects are actually using typescript-react-function-component-props-handler today on NPM or GitHub? (I will come back to that later.)

The short answer is: not many, at least not directly - which is fine. Despite that, the package still has respectable download numbers for something that hasn't been updated in five years.

A couple of easy sources of information:

1. npm: The graph on the package page and the “Versions” tab show weekly download trends:
   
   https://www.npmjs.com/package/typescript-react-function-component-props-handler?activeTab=versions

2. shields.io integration: A badge on the GitHub repo shows monthly downloads:
   
   https://github.com/Winner95/typescript-react-function-component-props-handler

Shields.io also lets you view open download data for different time ranges, which looks quite encouraging for a small utility module - roughly 8k downloads per year. If you maintain an open source project, integrating these badges can be a nice way to present usage information in a concise and visually appealing way. You can experiment with badges for npm packages and many other ecosystems here:

• https://shields.io/badges/npm-downloads

Side note: the npm graphs don't always provide detailed insights about comparing different version downloads data. I do wonder whether there are more advanced visualisation tools around these days. That alone could be an idea for another project.

Anyway, going back to the original goal: we now have some numbers showing how the tool is being used at the moment.

But what about the potential impact and use cases? This is where GitHub comes in handy.

Searching GitHub

I would like to say a few kind words about how good GitHub's search has become. The way you can query things on GitHub these days is genuinely convenient.

So we are going to look at GitHub search results to find the answer to this question: how many projects are using react-docgen (and specifically version 5) today? As I mentioned earlier, just the number of projects using my handler directly is relatively low, according to Github results. So the next step is to look at the broader ecosystem and see where the handler could be useful.

Step 1: Start broad

My first hypothesis was simply to use search results as they are and refine it to see if it makes sense to continue and take it from there. In other words, I was wondering

How many projects are using react-docgen in their package.json as a dependency?

Search query:

"react-docgen":  path:**/package.json

GitHub code search link (approx. 7.4k results):

• https://github.com/search?q=%22react-docgen%22%20path:**/package.json&type=code

So we started with around 7.4k results.

Step 2: Use a regex to find any react-docgen entry

We can simplify the query a bit and use a regex:

path:package.json /"react-docgen"/

GitHub search:

• https://github.com/search?q=path:package.json%20/%22react-docgen%22/&type=code

This query still only looks for the package name, but now using the new code search syntax with regex, which is quite handy and we confirm if results are consistent between 2 queries.

Step 3: Filter specifically for version 5

Next, I wanted to look only at projects using version 5 of react-docgen. So the search becomes:

path:package.json /"react-docgen"\s*:\s*"[~^]?5(\.|")/

This query tries to match any variant of version 5 of the package (for example, 5.0.0, ^5.2.1, ~5.3.0, and so on).

The result of filtered query is roughly 2.9k files it is already a nice reduction.

Step 4: Exclude generated or vendor directories

Some of these package.json files will inevitably belong to pre-generated code or even node_modules accidentally committed to a repo. That's not ideal if you're trying to focus on “real” projects. For that you need to focus on files that are not in pre-built folders.

So the next iteration adds some exclusions:

path:package.json /"react-docgen"\s*:\s*"[~^]?5(\.|")/ NOT path:node_modules NOT path:dist NOT path:build

GitHub search (about 2.4k files):

• https://github.com/search?q=path:package.json%20/%22react-docgen%22%5Cs*:%5Cs*%22%5B~^%5D%3F5(\.|%22)/%20NOT%20path:node_modules%20NOT%20path:dist%20NOT%20path:build&type=code

That is already a decent improvement and gives a more realistic set of projects.

Step 5: Exclude archived repositories

Next, I wondered: what if some of these repositories are already archived?

We can add NOT is:archived to the query:

path:package.json /"react-docgen"\s*:\s*"[~^]?5(\.|")/
NOT path:node_modules NOT path:dist NOT path:build NOT is:archived

GitHub search (around 2.3k files):

• https://github.com/search?q=path:package.json%20/%22react-docgen%22%5Cs*:%5Cs*%22%5B~^%5D%3F5(\.|%22)/%20NOT%20path:node_modules%20NOT%20path:dist%20NOT%20path:build%20NOT%20is:archived&type=code

We've trimmed another hundred or so repositories, which seems reasonable.

Step 6: Exclude forks

Finally, I wanted to focus on “original” projects rather than forks. So I added NOT is:fork:

path:package.json /"react-docgen"\s*:\s*"[~^]?5(\.|")/
NOT path:node_modules NOT path:dist NOT path:build NOT is:archived NOT is:fork

GitHub search (around 430 files):

• https://github.com/search?q=path:package.json%20/%22react-docgen%22%5Cs*:%5Cs*%22%5B~^%5D%3F5(\.|%22)/%20NOT%20path:node_modules%20NOT%20path:dist%20NOT%20path:build%20NOT%20is:archived%20NOT%20is:fork&type=code

That brings us down from roughly 7.4k to around 430 projects, which feels like a much more manageable and realistic list of repositories to go through - at least from looking through the first few pages.

At this point, the next question is: which of these repositories are still active this year? It would be nice to use something like updated:>2025-01-01 to filter by last update date... but GitHub code search politely reminds us:

“The updated qualifier is not supported when searching code.”

Fair enough. Even without that, we have already gone from ~7.4k to ~430 projects, which is quite a change.

You could imagine using other (AI) tools to cross-reference this list with actual repository metadata and confirm which projects are actively maintained in 2025. That would be a good use case in itself - but it would also take us off on a different tangent: building more complex search workflows for GitHub.

If you're interested in experimenting with GitHub search yourself, there's plenty of documentation available:

• https://github.com/search/advanced
• https://docs.github.com/en/search-github/getting-started-with-searching-on-github/about-searching-on-github
• https://docs.github.com/en/search-github/github-code-search/understanding-github-code-search-syntax

The main idea I wanted to show here is how you can get a first impression and a rough figure of the potential impact for your own tools and projects. My example was based on research of how many tools are using react-docgen of version 5.x today - and therefore how many projects could potentially benefit from improved prop generation that custom handler provides.

On a side note, a completely different idea came to my mind: based on GitHub search results, there is probably room for a commercial tool that helps you build more sophisticated queries and analyses. We will see what can be build, but maybe next time.

So, where does that leave us today?

Instead of an epilogue

So far, we have:

• outlined the potential impact of the project,
• captured some notes on how to work with open data for open source projects,
• collected a few side project ideas that can go onto the ever-growing TODO list.

That is enough to confidently say we have what we can try to start working on the project again.

I manually tested the custom code handler a long time ago, so the immediate next step is to add proper test cases and examples to ensure I am covering the main use cases.

And that is where I discovered that there was a pull request in the repository that I completely missed... three years ago.

More on that in the next chapter.