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.
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.