Table Of Contents

Back to Labs Content

  • Github
  • Package
  • Library
  • Software Development
  • Frontend

Creating a Reusable React Layout Package via GitHub (Without npm Publish)

Sunday, May 4, 2025 at 10:42:53 AM GMT+8


Do you copy-paste the same Navbar, Footer, or layout components into every React project you build? It works — but it’s messy and hard to maintain.

Here’s a better solution:

- Turn your layout into a reusable component package stored in a GitHub repo, and install it into any project using npm install.

What You’ll Build

You’ll create a shared layout repo that:

✅ Exports components like <Navigation/> and <Footer/>

✅ Can be installed via GitHub in any React project

✅ Can be versioned and updated cleanly using Git tags

1. Create the Shared Layout Project

You can use Vite to quickly scaffold a React setup:

npm create vite@latest personal-shared-layout --template react
cd personal-shared-layout
npm install

Now, delete the default App.jsx, main.jsx, and create your own components:

mkdir -p src/components
touch src/components/Navbar.jsx src/components/Footer.jsx src/index.js

2. Add Your Components

Example: src/components/Navbar.jsx

const Footer = () => (
  <footer style={{ background: '#111', color: 'white', padding: '1rem' }}>
    <p>© 2025 All rights reserved.</p>
  </footer>
);
export default Footer;

Export them in src/index.js

export { default as Navbar } from './components/Navbar.jsx';
export { default as Footer } from './components/Footer.jsx';

3. Configure package.json

Update your package.json to define the entry point and peer dependencies:

{
  "name": "personal-shared-layout",
  "version": "1.0.0",
  "type": "module",
  "main": "./src/index.js",
  "private": false,
  "peerDependencies": {
    "react": "^18.0.0",
    "react-dom": "^18.0.0"
  }
}

✅ main must point to your src/index.js

✅ peerDependencies means the consuming app provides React.

4. Push It to GitHub

git init
git remote add origin https://github.com/your-username/personal-shared-layout.git
git add .
git commit -m "Initial layout package"
git push -u origin main

5. Tag a Version

Use Git tags for clean versioning:

git tag v1.0.0
git push origin v1.0.0

You can later tag new versions like v1.0.1, v2.0.0, etc.

6. Use It in Other Projects

In any React app:

npm install git+https://github.com/your-username/personal-shared-layout.git#v1.0.0

Then import your shared components:

import { Navbar, Footer } from 'personal-shared-layout';

function App() {
  return (
    <>
      <Navbar />
      <main>My content</main>
      <Footer />
    </>
  );
}

7. Updating the Shared Layout

When you make changes to the shared repo:

# Commit your changes
git commit -am "Add feature or fix"

# Tag a new version
git tag v1.0.1
git push origin v1.0.1

Then in your other project:

npm install git+https://github.com/your-username/personal-shared-layout.git#v1.0.1

8. Bonus Tips

✅ Use SemVer (v1.0.0, v1.0.1, v2.0.0) for safe versioning.

✅ Pin versions with tags to avoid unexpected changes.

✅ You can later convert this into a real NPM package if needed.

 Conclusion

By turning your layout components into a shared GitHub package, you eliminate copy-paste duplication, ensure consistent UI across projects, and make updates effortless. It's a simple but powerful way to scale your frontend development—clean, versioned, and reusable without needing to publish to npm.


Another Recommended Labs Content

APIThrottlingSoftware DevelopmentRate Limiting

Throttling vs Rate Limiting: What’s the Difference and When to Use Each

Managing traffic is crucial for keeping systems reliable and stable, especially when handling a high volume of requests. Two techniques often come up in this context: rate limiting and throttling.

In this guide, you'll learn how to set up Expo push notifications for Android, including the correct use of Firebase Admin SDK credentials, how to upload them securely, and how to properly configure your Expo app.

FrontendSoftware ArchitectureSystem Design

The concept of splitting a frontend into smaller, manageable pieces.

Have you ever worked on a massive frontend application where every change felt risky and deploying updates took ages? If so, micro frontends might be the solution you’ve been looking for