2020-03-10
4566
#react
Ovie Okeh
15245
Mar 10, 2020 ⋅ 16 min read

The complete guide to publishing a React package to npm

Ovie Okeh Programming enthusiast, lover of all things that go beep.

Recent posts:

alexandra spalato ai hallucination quote

How to stop your AI agents from hallucinating: A guide to n8n’s Eval Node

Walk through a practical example of n8n’s Eval feature, which helps developers reduce hallucinations and increase reliability of AI products.

Alexandra Spalato
Sep 17, 2025 ⋅ 6 min read

Secure your AI-generated projects with these security practices

Secure AI-generated code with proactive prompting, automated guardrails, and contextual auditing. A practical playbook for safe AI-assisted development.

Ikeh Akinyemi
Sep 16, 2025 ⋅ 5 min read

Let’s kill vibe coding and bring back prompt engineering

Explore the vibe coding hype cycle, the risks of casual “vibe-driven” development, and why prompt engineering deserves a comeback as a critical skill for building better, more reliable AI applications.

Oscar Jite-Orimiono
Sep 16, 2025 ⋅ 11 min read
Frontend Devs Aren't Lazy, They're Burnt Out

Frontend developers are burned out, not lazy

Shipping modern frontends is harder than it looks. Learn the hidden taxes of today’s stacks and practical ways to reduce churn and avoid burnout.

Shalitha Suranga
Sep 15, 2025 ⋅ 4 min read
View all posts

6 Replies to "The complete guide to publishing a React package to npm"

  1. https://www.echojs.com/comment/35598/1

    —–

    For react components, be sure to have a peer-dependency with an appropriate range setup for your features used.

    For example:

    “peerDependencies”: {
    “react”: “>=16.11.0 <18.0.0"

    Start with the version of react you're testing against and up to the version after next. React does very well at not removing features until a version after next… in the example above, 16.11.0 has the feature needed, and your component is up to date, and not using anything marked deprecated. This way you can generally rely on the features in use until the version after next (18).

    —-

    On a typescript definition file, this also is beneficial to all users of VS Code, or where code completion is based on or enhanced by typescript definitions, including JS usage in VS Code.

    —-

    On publishing, if you're on a public repository, and you should probably be for public packages, you should use a CI/CD pipeline based on a trigger, tag or admin comment for a release on PR approval. It's relatively easy to automate.

    If you're creating a fork of an existing project, prefer namespacing for your package naming… it will help to avoid confusing names like foo3, etc where @yourid/foo would be better.

  2. Nice article. One comment and suggestion:

    From experience the packaging step shouldn’t be necessary. You really want allow your consumers to optimize their dependencies and reuse transient dependencies. So it’s important to define your dependencies as ranges. For example, if you use lodash version 4.* and another package uses lodash 4.*, the consumer of both only ends up with one copy (rather than two copied copied into each library bundle).

    Likewise, if you leave your output as transpiled (and not as a bundl) your consumer will be able to use tree shaking to reduce their bundle size. It’s import to publish your sideeffects in your package.json and have an optional ESM transpiled output. See https://webpack.js.org/guides/tree-shaking/

  3. I’ve a question. Suppose we want to keep the scss as it is. I’m creating a component library where all theme is defined in various scss variable files like, dimension.scss, colors.scss, fonts.scss etc.
    Variables look like, $primaryColor: #000000, $padding: 10px etc.
    rollup is always compiling my component css and bundling it. I would like my package to be used as it is defined in the variables. That way a new project can update/define the $primaryColor and theme it. Any help will be much appreciated.

  4. From the `npm` docs, just a tiny correction to the `scoped` packages default availability

    “When publishing scoped packages, the access level defaults to restricted. If you want your scoped package to be publicly viewable (and installable) set –access=public. The only valid values for access are public and restricted. Unscoped packages always have an access level of public.”

  5. If some of you getting error kind of this:
    [!] Only inline sourcemaps are supported when bundling to stdout.

    It would be solved by including “main”: “dist/index.js”

    Probably, it’s coming due to the experimental stage of importing json into rollup config

Leave a Reply