|
| 1 | +# Publishing to npm |
| 2 | + |
| 3 | +To publish to the npm registry you'll need to use the command `pnpm publish`. You should read the docs for that command before continuing. The documentation for `npm publish` is also a really useful reference and well worth a read. |
| 4 | + |
| 5 | +- [`pnpm publish`](https://pnpm.io/cli/publish) |
| 6 | +- [`npm publish`](https://docs.npmjs.com/cli/v11/commands/npm-publish) |
| 7 | + |
| 8 | +But before that, there are some steps you should take to check that everything is ready... |
| 9 | + |
| 10 | +## Reviewing `package.json` |
| 11 | + |
| 12 | +Let's imagine you created a project called `@skirtle/example-lib`. Your directory structure might be something like this: |
| 13 | + |
| 14 | +``` |
| 15 | +📁 example-lib |
| 16 | + 📁 packages |
| 17 | + 📁 docs |
| 18 | + 📄 package.json |
| 19 | + 📁 playground |
| 20 | + 📄 package.json |
| 21 | + 📁 example-lib |
| 22 | + 📁 src |
| 23 | + 📄 package.json ← This file |
| 24 | + 📄 package.json |
| 25 | +``` |
| 26 | + |
| 27 | +There are several `package.json` files, but for publishing the library to the npm registry, the important one is `packages/example-lib/package.json`. |
| 28 | + |
| 29 | +You should review that file carefully to ensure it has all the fields set correctly before you attempt to publish the package. Most important are the package's `name` and `version`. |
| 30 | + |
| 31 | +When that file is first created it will contain `"private": true`. That prevents the library from being published by accident. You'll need to remove that line when you're ready to make your first release. |
| 32 | + |
| 33 | +## Check the build |
| 34 | + |
| 35 | +You need to build the project before publishing: |
| 36 | + |
| 37 | +```sh |
| 38 | +pnpm build |
| 39 | +``` |
| 40 | + |
| 41 | +Check the files in `dist` all contain what you're expecting. Also check the `README.md`, which by default is copied to the main project directory from the root directory as part of the build. This file is included in the published package and is what people will see when they view your package via the npm website. |
| 42 | + |
| 43 | +## Do a dry run |
| 44 | + |
| 45 | +A 'dry run' will go through most of the steps of publishing the package but without actually adding it to the registry. Assuming you're in the main package directory (the one containing `package.json` and `dist`), run: |
| 46 | + |
| 47 | +```sh |
| 48 | +pnpm publish --tag=latest --access=public --dry-run --publish-branch=main |
| 49 | +``` |
| 50 | + |
| 51 | +If you have local files that aren't checked into git then you may need to add `--no-git-checks` too. |
| 52 | + |
| 53 | +The dry run will show which files are going to be included in the published package. pnpm should automatically include the `LICENSE` file, taken from the workspace root. The `README.md` isn't taken from the workspace root, so that's copied as part of the build. You should also see `package.json` and the files in `dist`. Files from `src` shouldn't be needed. |
| 54 | + |
| 55 | +## Authenticating |
| 56 | + |
| 57 | +Before you can publish you'll need to create an account on the npm registry. |
| 58 | + |
| 59 | +pnpm doesn't have a separate command to authenticate with the registry, it'll use the token in `.npmrc`. You can use the command `npm login` (note `npm`, not `pnpm`) to populate that token. See <https://docs.npmjs.com/cli/v11/commands/npm-login>. |
| 60 | + |
| 61 | +## Learn about unpublishing |
| 62 | + |
| 63 | +If you make a mistake when publishing a package, you can't easily undo it. |
| 64 | + |
| 65 | +Before you publish a package, you should also learn about how to *unpublish* a package. |
| 66 | + |
| 67 | +See <https://docs.npmjs.com/policies/unpublish>. |
| 68 | + |
| 69 | +## Publishing |
| 70 | + |
| 71 | +When you're finally ready to publish, the command is the same as we used earlier for the dry run, but without the `--dry-run` flag: |
| 72 | + |
| 73 | +```sh |
| 74 | +pnpm publish --tag=latest --access=public --publish-branch=main |
| 75 | +``` |
| 76 | + |
| 77 | +The package `name` and `version` will be taken from the `package.json`. |
| 78 | + |
| 79 | +## GitHub releases |
| 80 | + |
| 81 | +It's common to create a release on GitHub when publishing a package. This includes release notes for the release and adds a tag to the repository. |
| 82 | + |
| 83 | +## Automating the process |
| 84 | + |
| 85 | +This scaffolding tool doesn't currently have any support for automating this process, but you can find various examples of automation scripts if you look through the GitHub repos for large projects. |
0 commit comments