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:

Node.js 24: What's New

Node.js 24 is here: What’s new and what to expect

Discover what’s new in Node.js 24, including major features, improvements, and how to prepare your projects.

Yan Sun
May 20, 2025 ⋅ 5 min read
Building An Agentic AI Workflow With Ollama And React

Building an agentic AI workflow with Ollama and React

Build agentic AI workflows with Ollama and React using local LLMs for enhanced privacy, reduced costs, and offline performance.

Andrew Baisden
May 20, 2025 ⋅ 11 min read
Monorepos Vs. Polyrepos: Which One Fits Your Use Case

Monorepos vs. Polyrepos: Which one fits your use case?

Learn when to choose monorepos or polyrepos for your frontend setup by comparing coordination, dependency management, CI/CD requirements, and more.

Muhammed Ali
May 19, 2025 ⋅ 4 min read

SOLID series: The Open-Closed Principle

Today, we’ll be exploring the Open-Closed Principle: from the criticisms around it, its best use cases, and common misapplication.

Oyinkansola Awosan
May 16, 2025 ⋅ 11 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