scijs- module namespacing

[rreusser]

The ndarray packages kinda solve themselves, but should scijs module names be prefixed with scijs-? I think it's a reasonably polite thing to do in a global namespace, particularly one that encourages huge numbers of tiny modules. Another thing that's much easier to change sooner than later.

[mikolalysenko]

Agreed. Any other thoughts on this?

[Planeshifter]

I think it is a very good idea, too. 👍
With the proliferation of npm packages, many package names are already taken, so this decision would give us both more freedom in picking appropriate names while at the same time also promoting scijs as a project.

[kgryte]

This is currently what we do with compute. Another option is to create a shared NPM account, e.g., scijs, to which everyone publishes modules. This would allow for scoped packages and automatically would handle the namespace issue. The problem then is that contributors would then need to manage multiple NPM accounts and be sure to publish scijs modules with --access public.

Using scijs as a prefix does not prevent others not affiliated with the project from clobbering the namespace. But then, a shared acct requires managing acct access, which may prove difficult if members come and go.

Just thought I would propose one other alternative.

[Planeshifter]

If we had a scijs account, packages would be installed via npm install @scijs/project-name. I am not sure whether this is preferable to npm install scijs-project-name or not. There is one major reason why this might not be a viable alternative, though: scoped packages seem to be made for intraorganizational or private modules only. They do not appear in the npm search results, for example.

[kgryte]

Scoped packages not appearing in search results is temporary. There is work being done to fix this.

[rreusser]

I favor the scijs- prefix for simplicity. There aren't so many of us, but sharing account creds is usually pretty unpleasant, plus—unlikely though it may be—it seems like a SPOF if someone gets the bright idea to change the password or something.

[rreusser]

The shared account idea is interesting, but it sounds to me like the safest option is just renaming with a scijs- prefix. If handled correctly, should just be a slow transition as things get switched over. It probably also makes sense as that happens to make some sort of push for more consistent returns/exceptions/testing, as discussed previously.

As for procedure, I'm new to managing npm modules, but if done correctly, I guess it's not so bad. Perhaps:

• if an ndarray-* package, just leave well enough alone at the moment since they're already basically prefixed, although probably makes sense to eventually prefix everything.
• otherwise:
  • rename the github repo to add scijs- prefix. github seems pretty good about redirecting gracefully.
  • check out 'deprecation' branch and replace readme with a notice redirecting to new npm module
  • publish readme with redirect to the old npm module page and then deprecate it
  • publish the new scijs-prfixed module

Sorry to belabor this; I'm open to absolutely any feedback or someone overriding decisions or whatever; just trying to solve some problems ahead of time instead of too far after the fact.

[rreusser]

(And yes, if you're watching github history, I was having some brain problems while trying to apply this procedure ten minutes ago, but I think my brain is fixed now. 😄 )

[rreusser]

I'll shut up, but never mind about switching the github repo names. Unnecessary.