You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first time I published this plugin as a package (v2.3.4), I published it to the npmjs registry under the name jquery-clock-plugin.
The next time I published the plugin as a package, I published it to the Github package registry. The Github package registry requires scoped packages, so I changed the name to @johnrdorazio/jquery-clock-plugin.
A few years have passed, and now I have dedicated some time creating the latest version v2.3.7, and I successfully published again to the Github registry. However I noticed that you can't simply do a yarn add @johnrdorazio/jquery-clock-plugin to retrieve the package (perhaps you need to set the registry to look into first?).
I would like to keep it as simple as possible for users, if anyone were to try to use the package with npm or yarn. So I figured, why not publish to both registries, then anyone can simply pull from the registry they prefer.
However, publishing to both registries is not very straightforward. I have attempted at creating workflows to automate the process, and I have created access tokens both for the Github registry and for the NPMJS registry. I had a heck of a time publishing to the NPMJS registry even from the command line, I finally succeeded by modifying package.json's name key to a value of jquery-clock-plugin and modifying the publishConfig.registry key to the npmjs registry.
For the time being, I am attempting to do just this with the publish workflow: the npmjs registry workflow will modify package.json with the updated values using sed.
Perhaps another possibility is to not use the publishConfig key in package.json, which effectively overrides any .npmrc settings, and just use .npmrc? See here: https://stackoverflow.com/a/58618271/394921 .
The text was updated successfully, but these errors were encountered:
and perhaps to keep things simple, without having to change the name of the package, would be to unpublish the package from the npmjs registry and re-publish it under the @johnrdorazio scope? That way we probably wouldn't have to be changing the name when publishing to multiple registries...
The first time I published this plugin as a package (
v2.3.4
), I published it to the npmjs registry under the namejquery-clock-plugin
.The next time I published the plugin as a package, I published it to the Github package registry. The Github package registry requires scoped packages, so I changed the name to
@johnrdorazio/jquery-clock-plugin
.A few years have passed, and now I have dedicated some time creating the latest version
v2.3.7
, and I successfully published again to the Github registry. However I noticed that you can't simply do ayarn add @johnrdorazio/jquery-clock-plugin
to retrieve the package (perhaps you need to set the registry to look into first?).I would like to keep it as simple as possible for users, if anyone were to try to use the package with npm or yarn. So I figured, why not publish to both registries, then anyone can simply pull from the registry they prefer.
However, publishing to both registries is not very straightforward. I have attempted at creating workflows to automate the process, and I have created access tokens both for the Github registry and for the NPMJS registry. I had a heck of a time publishing to the NPMJS registry even from the command line, I finally succeeded by modifying
package.json
'sname
key to a value ofjquery-clock-plugin
and modifying thepublishConfig.registry
key to the npmjs registry.For the time being, I am attempting to do just this with the publish workflow: the npmjs registry workflow will modify
package.json
with the updated values usingsed
.Perhaps another possibility is to not use the
publishConfig
key inpackage.json
, which effectively overrides any.npmrc
settings, and just use.npmrc
? See here: https://stackoverflow.com/a/58618271/394921 .The text was updated successfully, but these errors were encountered: