Forem: Ivan G.

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

Ivan G. — Mon, 08 Dec 2025 13:22:13 +0000

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:

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
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:

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.

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

Ivan G. — Tue, 02 Dec 2025 17:14:45 +0000

Revisiting Old Open Source Projects in 2025

A lot can change in five years. I recently realised I hadn’t opened my GitHub profile in almost three years. Part of the reason was that notifications stopped working properly at some point. I remember one day being flooded with random spam notifications… and then suddenly stopped receiving anything at all, after setup notifications. Not the best experience when you’ve got 20+ projects to maintain.

Moreover, life gets busy, so these things happen. In 2025 I decided it was time to revisit my projects there, one at a time.

The first question I had to ask myself was simple: which projects are worth keeping maintained, and which should be archived?

This article shares some general ideas that helped me to decide. Hopefully they will be useful to you too.

How to decide what to keep

My goal in 2015, 2020 and 2025 remains simple and straightforward: to share solutions and ideas that solve real challenges in the frontend or full-stack development world.

Here are three simple steps that I find useful:

Is the project still relevant?
- Does this project solve a problem that developers still have today?
- Can I reasonably expect other projects to benefit from it in 2025 and beyond?
Scope and context
- What exactly does the tool do?
- What doesn't it do, and what shouldn't it try to do?
- A clear, focused scope makes it easier to maintain and easier for others to understand.
Simplicity and usability
- Keep usage simple: the most common use cases should be easy to understand from the 'README'.
- Provide enough context in the documentation:
  - Why does this project exist?
  - When should someone use it (or not use it)?
- Try to avoid “clever” APIs, fix-it-all tool, if they make the learning curve steeper for no real benefit.

If a project scores well on relevance, scope, and usability, it is usually a good candidate to keep, polish, and improve rather than archive.

How to maintain it

Once you have decided a project is worth keeping, the next question is: how do you maintain it realistically?

Set a realistic timeline
- Decide how often you can look at the project (monthly, quarterly, etc.).
- It doesn't have to be perfect; it just has to be sustainable for you.
Be transparent about updates
- Don't let all communication live only in the GitHub repo and the NPM registry.
- Share updates somewhere else too, for example:
  - Dev.to posts
  - LinkedIn updates
  - A short changelog in the README
- This helps people understand whether the project is still active and what's changing.
Minimise product-based dependencies
- Aim for zero or minimal third-party product dependencies where it makes sense.
- This reduces the surface area for security issues and version conflicts.
- In 2025, this still feels like a solid approach for JS/TS and Node.js projects, especially for small libraries and tools.
Follow software development best practices
Even for small open source tools, a little bit of discipline makes a big difference:
- A clear release cycle definition (even if it's “when needed, but documented”).
- Automated tests for the core functionality.
- CI/CD pipelines (e.g. GitHub Actions) for tests and releases.
- Linting and formatting rules to keep contributions consistent.
- Documentation updates with each release so users aren't guessing.
- Semantic Versioning (SemVer) and Git tags for every release so people can rely on versioning.

You don't have to implement everything at once, but having these as a long-term checklist can really help keep the project healthy.

So… is it worth it?

If you're a frontend or full-stack developer wondering:

“Does it still make sense to revive or create open source projects in 2025?”

My answer is still: yes.

It just needs to be more intentional:

choosing what is worth maintaining,
keeping the scope / context clear,
and treating even small libraries with a bit of professional care.

This is the first article in a small series about revisiting old projects and open source maintenance in 2025.

How to set up showcase of your React UI-components using GitHub Pages

Ivan G. — Sun, 13 Sep 2020 15:21:22 +0000

My Workflow

My workflow is based on the use of existing GitHub actions, small script for building Styleguide example and hosting results on GitHub Pages.

You can use it for building an example for hosting your own visual documentation / components or static website demo. The same workflow with any react UI library or building tool - Storybook, Styleguidist or any other:)

One of the main benefits - on each push / pull request in main branch of your repo, you will automatically get an up-to-date version of your UI Library or App.

Submission Category:

DIY Deployments

Yaml File or Link to Code

5 quicks steps to run

After you perform initial setup, which consists of:

create your own Personal Access Token on GitHub setting page. Use this access token as the password in code below, not your actual account password.
setup your GitHub username as USERNAME and remote url as REMOTE_URL (for example https://github.com/winner95/styleguide.git) in GitHub Secrets.
setup GitHub Pages for your repo.
create file .github/workflows/publish-docs.yml in your repo.
paste the following code:

name: Styleguide-build
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE,
      # so your job can access it
      - uses: actions/checkout@v2

      # Runs a single command using the runners shell
      - name: setup node
        uses: actions/setup-node@v1
        with:
          node-version: 12.18.3

      # install javaScript dependencies
      - run: yarn install
      # this is a line, which you can change 
      # to your own building script
      - run: yarn styleguide --buildDir ./docs

      # deploy action
      - name: GitHub Pages Deploy
        uses: appleboy/gh-pages-action@v0.0.2
        with:
          username: ${{ secrets.USERNAME }}
          password: ${{ secrets.PASSWORD }}
          remote_url: ${{ secrets.REMOTE_URL }}

Try to push any change to your repo.

Congratulations! You can find the results of your build on GitHub Pages. In my case via this link.

Additional Resources / Info

In my case the build take up to 1 minutes with installation of dependencies, which is quite fast.

Typescript & React.js: how-to lists

Ivan G. — Mon, 07 Sep 2020 21:42:00 +0000

While I was working on my recently published article about how to move large-scale React UI-components codebase to TypeScript I gathered a plethora of useful information about technical aspects of writing React UI-components and TypeScript. I grouped these resources together in separate lists.

Articles on choosing between JavaScript/TypeScript for codebase:

Articles on setting TypeScript for codebase:

Articles on moving existing react codebase to TypeScript:

Articles on writing new react codebase in TypeScript:

Articles for deeper dive in TypeScript:

Building online portfolio and profiles for personal brand

Ivan G. — Sun, 06 Sep 2020 10:24:28 +0000

I was thinking a lot about what platform to use to write about tech related themes. After Codepen decided to move blogs to dev.to I decided to finally try it:)

I would like to focus one of my first posts on show examples of online portfolios/profiles. I will start with small list:

It is most common platforms, which I encountered for the last couple of years. If you would like to share any platforms - feel free to add it in comments:)