DEV Community: Chintan prajapati

🚀 Stop Killing Your Bundle Size

Chintan prajapati — Fri, 26 Dec 2025 01:11:26 +0000

Automatically Remove Barrel Files in TypeScript

We all love Barrel Files (index.ts files that export everything from a directory). They make our imports look clean and organized:

// 😍 Looks clean...
import { Button, Header, Footer } from './components';

But what if I told you that this single line of code is likely slowing down your CI/CD, bloating your bundle size, and causing those nightmare "Module is undefined" circular dependency errors?

I built a tool to fix this automatically, and today I’m sharing it with you.

The Hidden Cost of Barrel Files 📉

When you import a single named export from a barrel file, many bundlers and test runners (like Jest) end up loading every other file exported in that barrel to resolve the module.

Slower Tests: In Jest, importing Button might accidentally load Table, Chart, and HeavyLibrary just because they share an index.ts.
Tree-Shaking Failures: Webpack and Rollup are getting better, but deeply nested barrel files often trick them into including dead code in your production bundle.
Circular Dependencies: This is the big one. If Module A imports Module B via an index, and Module B imports Module A via the same index, you get a runtime crash.

The Solution: Direct Imports 🛠️

The fix is simple but tedious. You need to convert this:

import { Button } from './components';

Into this:

import { Button } from './components/Button';

Doing this manually for 500+ files is painful. So I automated it.

Introducing: `no-barrel-file`

I created an open-source CLI tool and GitHub Action that scans your project, finds imports relying on barrel files, and automatically rewrites them to direct paths.

✨ Features

Auto-Fix: Rewrites imports safely using ts-morph (AST transformation, not regex).
Smart: Respects your tsconfig.json paths and aliases.
Flexible: Run it via npx, install it globally, or run it in CI.

💻 3 Ways to Use It Locally

Whether you want a quick check or a permanent tool for your team, there are three ways to use no-barrel-file.

Method 1: The "One-Off" (No Install)

The easiest way to check a project without installing dependencies is via npx.

# Just list the barrel files
npx no-barrel-file display

# Fix the imports
npx no-barrel-file replace --alias-config-path tsconfig.json

Method 2: The "Project Standard" (Dev Dependency)

If you want to ensure your whole team avoids barrel files, install it as a dev dependency.

npm install -D no-barrel-file
# or
pnpm add -D no-barrel-file

Then, add a script to your package.json:

"scripts": {
  "fix:barrels": "no-barrel-file replace --alias-config-path tsconfig.json",
  "check:barrels": "no-barrel-file display"
}

Now anyone on the team can run npm run fix:barrels.

Method 3: The "Power User" (Global Install)

If you work across many repositories and want this tool available everywhere in your terminal:

npm install -g no-barrel-file

# Now you can run it anywhere
no-barrel-file display

🤖 Automate it with GitHub Actions

The best way to maintain code quality is to automate it. I published a GitHub Action so you can ensure no new barrel files creep into your repository.

Option A: Auto-Fix Mode (Recommended)

This workflow detects lazy imports in Pull Requests, fixes them automatically, and pushes the changes back to the branch.

File: .github/workflows/fix-barrels.yml

name: Auto-Fix Barrel Files
on: [pull_request]

permissions:
  contents: write # Required to commit changes

jobs:
  fix-imports:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run No Barrel File
        uses: chintan9/no-barrel-file@v1
        with:
          mode: 'replace'
          alias-config-path: 'tsconfig.json'
          extensions: '.ts,.tsx'

      - name: Commit changes
        uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "refactor: resolve barrel file imports"

Option B: Audit Mode

If you prefer not to touch the code automatically but just want to see a report of barrel files in your CI logs:

- name: Audit Barrel Files
  uses: chintan9/no-barrel-file@v1
  with:
    mode: 'display'
    root-path: 'src'

Results

After running this on a medium-sized React project, I saw:

Jest startup time: Reduced by ~30%.
Circular Dependency Errors: Completely vanished.
Bundle Size: Slight reduction (depending on your existing tree-shaking setup).

Try it out!

I’d love to hear your feedback. Give it a star on GitHub if it saves you some time!

📦 NPM: npmjs.com/package/no-barrel-file
🐙 GitHub: github.com/chintan9/no-barrel-file

Happy coding! 🚀

Plyr-react V6

Chintan prajapati — Sat, 20 Dec 2025 05:07:54 +0000

plyr-react v6 modernizes the API, tightens TypeScript typings, and simplifies lifecycle behavior—expect a small set of breaking changes but a much clearer migration path and better DX.

Design goals and why they matter

v6 was driven by three practical goals: clarity, type safety, and predictability. The public surface was intentionally narrowed so consumers only rely on well-documented, stable exports. TypeScript-first typings reduce runtime surprises and make editor tooling actually helpful. Lifecycle and concurrency fixes address real-world flakiness when players mount/unmount rapidly in React apps. These changes make the library easier to maintain and safer to use in production, especially in large codebases and CI pipelines.

Key design decisions (technical summary)

Named public API: The component and hook are explicit exports. This reduces accidental reliance on internal utilities and enables better tree-shaking.
Hook-first ergonomics: usePlyr is the recommended path for imperative control; the component remains for simple declarative use. The hook returns a typed instance and stable attach/detach helpers.
Stronger typings: Events are modeled as discriminated unions and the player instance exposes typed methods (play, pause, seek, on, off). This eliminates many any casts and improves DX.
Lifecycle hardening: Initialization waits for the DOM node, defers non-critical setup, and guards against concurrent inits; cleanup is idempotent to avoid double-destroy errors.
Distribution clarity: ESM and CJS entry points are preserved, and CSS is consolidated to a single canonical import path to avoid bundler surprises.

Real-world migration examples

Below are concise, practical changes you’ll make when upgrading from v5 → v6.

1) Update package and imports

npm install plyr-react@^6.0.0

// v5
import Plyr from 'plyr-react';
import 'plyr-react/plyr.css';

// v6
import { Plyr, usePlyr } from 'plyr-react';
import 'plyr-react/dist/plyr.css';

Important: v6 uses named exports and a consolidated CSS path—update imports accordingly.

2) Flattened props and typed callbacks

// v5 style
<Plyr
  source={{ type: 'video', sources: [{ src: '/video.mp4' }] }}
  options={{ controls: ['play', 'progress'] }}
  onReady={(player) => { /* untyped */ }}
/>

// v6 style
<Plyr
  source={{ type: 'video', sources: [{ src: '/video.mp4' }] }}
  controls={['play', 'progress']}
  onReady={(instance: PlyrInstance) => { /* typed instance */ }}
/>

Important: Some props were flattened or renamed; check the changelog for exact mappings.

3) Using `usePlyr` for advanced control

import { useRef, useEffect } from 'react';
import { usePlyr } from 'plyr-react';

function Advanced() {
  const ref = useRef(null);
  const { instance, attach } = usePlyr();

  useEffect(() => { if (ref.current) attach(ref.current); }, [attach]);

  useEffect(() => {
    if (!instance) return;
    instance.on('timeupdate', (e) => { /* typed payload */ });
    return () => instance.off('timeupdate');
  }, [instance]);

  return <div ref={ref} />;
}

Important: usePlyr gives explicit attach/detach control and a typed instance—prefer it for complex integrations.

Testing and rollout tips

Run tsc --noEmit to catch typing regressions.
Smoke test play/pause/seek/fullscreen in a headless browser.
Search for internal imports in your codebase and replace them with public types and APIs.

v6 trades a few breaking changes for long-term stability, better DX, and fewer runtime surprises.

https://github.com/chintan9/plyr-react

plyr-react

Chintan prajapati — Fri, 25 Sep 2020 20:06:50 +0000

Release new version of plyr-react@3 with typescript.

Here you can see in action.

https://stackblitz.com/edit/react-r8vmzh?embed=1&file=src/App.js&hideExplorer=1&hideNavigation=1&view=preview

chintan9 / plyr-react

A simple, accessible and customisable react media player for Video, Audio, YouTube and Vimeo

Plyr React

A responsive media player that is simple, easy to use, and customizable for video, audio, YouTube, and Vimeo

You can see a live demo here.

Make sure to select the version for the plyr-react in the dependencies.

Installation

# NPM
npm install plyr-react

# Yarn
yarn add plyr-react

Usage

Ready to use `<Plyr />` component

The simplest form of react integration with the plyr is to use the <Plyr /> component, it is best for the static videos.

import Plyr from "plyr-react"
import "plyr-react/plyr.css"

const plyrProps = {
  source: undefined, // https://github.com/sampotts/plyr#the-source-setter
  options: undefined, // https://github.com/sampotts/plyr#options
  // Direct props for inner video tag (mdn.io/video)
}

function MyPlyrVideo() {
  return <Plyr {...plyrProps} />
}

Old version 4 plyr-react - The path for an import of css styles has been changed in version 5, if you are using…

View on GitHub

Selection Recovery Site of Location in Business Continuity

Chintan prajapati — Tue, 19 May 2020 18:31:09 +0000

Selection Recovery Site of Location in Business Continuity

While there are a number of important considerations to take into account when planning your business continuity efforts, the one we hear about time and again is how much distance is really necessary between the main work site and a disaster recovery site.

Serious business interruptions are now measured in minutes rather than hours.

Because electronic transactions and communications take place so quickly, the amount of work and business lost in an hour far exceeds the toll of previous decades. In the words of the Disaster Recovery, there is no rule of thumb when it comes to the appropriate distance between your data center and your recovery site.

Between 2007 and 2010, however, the average distance between a primary data center and its furthest backup data center seemed to shrink the majority of surveyed companies that had disaster recovery sites appeared comfortable with distances of less than 100 miles, and many were comfortable with distances of less than 25 miles.

Nonetheless, the components of integrated business continuity are the same: recovery options for facilities, technology, network infrastructure and human skills. However, the key to business continuity lies in understanding one’s business and determining which processes are critical to staying in that business and identifying all the elements crucial to those processes — specialized skills and knowledge, physical facilities, training and employee satisfaction as well as information technology.

If you are thinking about a secondary disaster recovery site for your business data, take the following questions into consideration:

Is there enough distance between your main site and your disaster recovery site to escape the same set of threats?

If your business is in the line of fire of hurricanes, for example, then you will want to look for a recovery site that is more than 100 miles away from your main site this should prevent a hurricane event from taking out both your main site and your recovery site. So, the decision is obviously left to the companies themselves — and such decisions cannot be made based on someone’s feeling, but on a study.

A Risk Assessment that involves identifying a potential risk event, assessing the likelihood of the event occurring, and defining the severity of the event’s consequences.

Risks could be anything from a power outage or hardware failure to a tornado or flood. Here are the factors that tend to push the location further away:

Earthquakes — if your location is in a seismic-sensitive area

Floods — you should position an alternative site out of the same flood plain

Tsunamis — you shouldn’t place both primary and secondary location on the coast of an ocean

Other natural disasters — e.g. forest fires, tornados/hurricanes,volcanos — if your primary site is close to such areas,

the disaster recovery site should be further away Large industrial facilities, nuclear power plants, or military installations — again,

at least one of your locations should be at a safe distance Dependence on the same source of electrical power.

you should look for locations on a different power grid pandemic diseases — in such cases, authorities will likely close the whole metropolitan area.

However, there are some factors that force you to position a disaster recovery location as close as possible:

Telecommunication links — the further the sites are away, the more difficult it becomes (i.e. more costly) to replicate the data between these sites.

If your employees are expected to travel to an alternative site in case of disaster — they have to be able to make it within the RTO (Recovery Time Objective); besides, the road between the sites shouldn’t be full of bridges and tunnels.

The goal for companies with no business tolerance for downtime is to achieve a state of business continuity, where critical systems and networks are available no matter what happens. This means thinking proactively; engineering availability, security and reliability into business processes from the outset — not retrofitting a disaster recovery plan to accommodate ongoing business requirements.

For all the sophisticated technologies available today, according to analyst reports,approximately 75 percent of the world’s data is still protected from copying it to magnetic tape and shipping it off to some secure off-site storage. At its most basic level, choosing the right disaster recovery technology is a business decision. As a result, before IT departments can decide on a disaster recovery technology, they have to establish the business priorities and objectives that the technology will be required to meet.

This step can be one of the most challenging for IT because it involves reaching across the aisle to the business side.“Immediately” and “none” are the two most common answers from department heads when asked how fast data needs to be recovered (RTO) and how much data they can afford to lose(RPO).

At its most basic level, choosing the right disaster recovery technology is a business decision.

Establishing appropriate, realistic and affordable RTO and RPO levels needs to be negotiated between the IT department and business leaders. It’s often a balancing act. Having an outside,unbiased business continuity planner present during these discussions helps them proceed to mutually acceptable conclusion.

When recovering data or systems across a significant distance, slower recovery times and bandwidth costs can negatively impact business continuity goals.

When answering the question of how far away a DR site should be from the primary site, then, it’s a matter of mitigating shared risks, not measuring miles.

By Chintan prajapati on September 26, 2015.

Canonical link

DEV Community: Chintan prajapati

🚀 Stop Killing Your Bundle Size

Automatically Remove Barrel Files in TypeScript

The Hidden Cost of Barrel Files 📉

The Solution: Direct Imports 🛠️

Introducing: no-barrel-file

✨ Features

💻 3 Ways to Use It Locally

Method 1: The "One-Off" (No Install)

Method 2: The "Project Standard" (Dev Dependency)

Method 3: The "Power User" (Global Install)

🤖 Automate it with GitHub Actions

Option A: Auto-Fix Mode (Recommended)

Option B: Audit Mode

Results

Try it out!

Plyr-react V6

Design goals and why they matter

Key design decisions (technical summary)

Real-world migration examples

1) Update package and imports

2) Flattened props and typed callbacks

3) Using usePlyr for advanced control

Testing and rollout tips

plyr-react

chintan9 / plyr-react

A simple, accessible and customisable react media player for Video, Audio, YouTube and Vimeo

Plyr React

Installation

Usage

Ready to use <Plyr /> component

Selection Recovery Site of Location in Business Continuity

Selection Recovery Site of Location in Business Continuity

Introducing: `no-barrel-file`

3) Using `usePlyr` for advanced control

Ready to use `<Plyr />` component