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:

The Replay (10/22/25): AI-assisted coding, Wasm 3.0, and more

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 22nd issue.

Matt MacCormack
Oct 22, 2025 ⋅ 29 sec read
Where AI-assisted coding accelerates development — and where it doesn’t

Where AI-assisted coding accelerates development — and where it doesn’t

John Reilly discusses how software development has been changed by the innovations of AI: both the positives and the negatives.

John Reilly
Oct 22, 2025 ⋅ 12 min read
Debugging with Chrome DevTools MCP: Giving AI eyes in the browser

Debugging with Chrome DevTools MCP: Giving AI eyes in the browser

Learn how to effectively debug with Chrome DevTools MCP server, which provides AI agents access to Chrome DevTools directly inside your favorite code editor.

Emmanuel John
Oct 21, 2025 ⋅ 6 min read
Goodbye, useState? Smarter state modeling for modern React apps

Goodbye, useState? Smarter state modeling for modern React apps

Ever opened a React file and found a graveyard of useState hooks? The problem isn’t React; it’s how we model state. Here’s how to do it smarter.

Oscar Jite-Orimiono
Oct 21, 2025 ⋅ 9 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

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now