Is it worth publishing on npm?

[christianbundy]

What's the problem you want solved?

Publishing on npm is a total hassle and I'm not sure how worthwhile it is.

• Maintainers need to make accounts on npm, which is an extra step that provides questionable value.
• Keeping GitHub maintainers synced with npm maintainers is a chore.
• Since the oasis name was taken I used a @namespace, which apparently means you can't add maintainers to a module. You must add them to an organization, and then add them to a team, and add the team to the module. This will only take a few minutes but I imagine that means everyone has to join the 'organization' and accept the team invite? 🤷‍♂️
• If we publish on npm then now we have an npm publish command that we have to run just to replicate what we've already just released with git push.

Is there a solution you'd like to recommend?

We're already pushing our code and tags to GitHub, and it's trivial to have npm install the latest semver tag from GitHub:

npm --global install "fraction/oasis#semver:*"

Should we just do that and avoid publishing on npm? Or is it friendlier to just follow the 'publish on npm' convention and don't sweat the slightly increased complexity?

[cinnamon-bun]

It'd be nice for our code to exist somewhere besides just GitHub. That could be npm or another git hosting service.

Is that npm command line hardcoded to github or can it use other git hosts?

If someone wanted to use Oasis as a dependency, how would that work without npm? For example if someone made an Oasis launcher app like in #172 (comment)

I wish we could use entropic instead of npm but it looks stalled. No commits in 2020

[christianbundy]

Is that npm command line hardcoded to github or can it use other git hosts?

You can use any Git host, which is pretty cool IMO. I think you just have to use a full URL instead of the GitHub short name.

If someone wanted to use Oasis as a dependency, how would that work without npm?

You can use Git URLs as dependencies, and honestly my anti-registry sentiments are leaning toward doing this for all dependencies, but it's unconventional and I really don't want Oasis to just be a bunch of experiments that are impossible to reason about. If you run npm install fraction/oasis#semver:^2.13.0 it should work exactly like if you ran npm install @fraction/oasis@^2.13.0

I wish we could use entropic instead of npm but it looks stalled.

I don't know whether it has any merit, but my mind keeps falling back into this hot take that Registries Are Bad -- or at least that Git gives us everything that the npm registry gives us without any of the problems that come with a walled garden.

[christianbundy]

Maybe worth discussing: should we even be advertising a "stable" version that requires that we bump package.json and release to npm? Seems like the ideal would be to just have everyone on the latest commit from master, upgrading whenever they have time.

---

Edit: on second thought, this really only works for the npm install and probably isn't what we want to do long-term.

[jedahan]

How does #semver: work? Is it just a branch? What's the difference between that and npm --global install "fraction/oasis@2.13.0"

I think the "Publishing to npm is a hassle" we can work on, with one possible solution being 'stop publishing on npm' another being 'make an org and distribute the publish load' and others making publishing easier.

[christianbundy]

Full docs are here, but in summary if you're installing from a Git source then you can add a commit-ish (commit, branch, tag, etc) at the end like:

npm install fraction/oasis#v2.13.0

Unfortunately that means you can't do ^2.13.0 or anything, so there's a special syntax #semver:^2.13.0 that looks at all of the tags and downloads the correct one. If you do #semver:* it does the latest semver tag.

I guess the root is: the npm registry is basically a centralized mirror, do we need it or should the installers pull directly from where we host our source code (currently GitHub, but any Git host would work)?

[jedahan]

Its tough to know what barriers there are for contributing, and if hosting on npm has any effect.

[jedahan]

Although I would love to move away from centralized registries, I am also happy to create an org and invite us all to it for now, and when we have more than say 10 contributors revisit moving away from npm?

Alternatively, we can just change the install instructions to the semver 'stable' instructions . (npm install fraction/oasis#v2.13.0) and maybe mention it in some doc about how to release - update package.json and readme.

I think the default branch will have bugs, so its nice to have a rough consensus of "after enough interesting changes / time to settle, make a release!".

[christianbundy]

Alternatively, we can just change the install instructions to the semver 'stable' instructions .

In the original post I suggested:

npm install "fraction/oasis#semver:*"

Is there a reason you'd prefer hardcoding the tag? The command I'm suggesting fetches the tags from the repo and installs the latest semver tag, which I think is what we want. No requirement to update the readme. 🎉

[jedahan]

mainly that it feels more accessible to me, as it is slightly more familiar. maybe it doesn't matter.

[cinnamon-bun]

Does the central npm instance actually store copies of the code of each module, or does it expect github etc. to do that?

I'm nervous having the code only exist on github which sometimes gets blocked in various countries. I could set up a mirror on GitLab as another solution.

[christianbundy]

Does the central npm instance actually store copies of the code of each module, or does it expect github etc. to do that?

It stores the output of npm pack with some metadata changes to package.json and such, so it's our source code plus some npm metadata minus any of the Git integration.

I could set up a mirror on GitLab as another solution.

Git integration would be awesome, I'd love to set up mirrors and reduce the power of GitHub. It's fine for now (unless anyone wants to move now?) but I'd love to have migration paths and mirrors so we don't depend on GitHub 100%.