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:

Stagehand and Gemini logos on a gradient background symbolizing AI web automation

How to build a web-based AI agent with Stagehand and Gemini

This guide walks you through creating a web UI for an AI agent that browses, clicks, and extracts info from websites powered by Stagehand and Gemini.

Elijah Asaolu
Jul 4, 2025 ⋅ 8 min read
Getting Started With Claude 4 API: A Developer's Walkthrough

Getting started with Claude 4 API: A developer’s walkthrough

This guide explores how to use Anthropic’s Claude 4 models, including Opus 4 and Sonnet 4, to build AI-powered applications.

Andrew Baisden
Jul 3, 2025 ⋅ 16 min read
ai dev tool power rankings

AI dev tool power rankings & comparison [July 2025 edition]

Which AI frontend dev tool reigns supreme in July 2025? Check out our power rankings and use our interactive comparison tool to find out.

Chizaram Ken
Jul 2, 2025 ⋅ 3 min read
how API client automation can save you hours in development

How API client automation can save you hours in development

Learn how OpenAPI can automate API client generation to save time, reduce bugs, and streamline how your frontend app talks to backend APIs.

Lewis Cianci
Jul 1, 2025 ⋅ 7 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