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:

Error Handling In Rust A Comprehensive Guide

Error handling in Rust: A comprehensive tutorial

Learn to handle Rust errors efficiently to write cleaner, more maintainable Rust code and create a more user-friendly application.

Eze Sunday
Jul 18, 2024 ⋅ 10 min read
Exploring Actions And Request Rewriting In Astro

Exploring actions and request rewriting in Astro

Astro v4.8 ships with server actions and request rewriting. Let’s see how to use these long-awaited (though still experimental) features.

Ivaylo Gerchev
Jul 17, 2024 ⋅ 13 min read
Comparing Fiber Vs Gin For Go Web Development

Comparing Fiber vs. Gin for Go web development

Go Fiber and Gin are two popular Go frameworks that provide extensive toolkits for developing high-performance apps with modern features.

Temitope Oyedele
Jul 17, 2024 ⋅ 8 min read
Leveraging Typescript Branded Types For Stronger Type Checks

Leveraging TypeScript branded types for stronger type checks

Branded types in TypeScript allow us to write code more clearly, provide more type-safe solutions, and maintain our code more efficiently.

Rashedul Alam
Jul 16, 2024 ⋅ 5 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