What should we do about purescript- prefixes?

Historically the PureScript community has used a purescript- prefix on package names. For example, the aff package is in the purescript-aff repository, and it is registered on Bower under the name purescript-aff. This applies to the compiler and Pursuit, too: the purs publish command considers the "package name" to be whatever came from a bower.json's name field, and Pursuit does the same thing.

However, when we stopped depending on Bower, we moved away from prefixes. aff may be in the purescript-aff repository, but its spago.dhall file and its name as far as the package sets are concerned is aff.

With the registry this goes a step further. Packages in the registry are registered without the prefix, and their name is recorded in the purs.json manifest file without the prefix. As far as the registry is concerned (and its products, such as the package sets) there is no usage of the prefix.

This leaves us in an inconsistent state where some tooling and some conventions use the prefix and some do not. For example:

• Repositories will continue to use purescript- in their name
• Bowerfiles (for packages that continue to use them) will use purescript- in the Bowerfile package name
• The registry, purs.json manifest, and package sets do not use the prefix for package names
• purs publish can accept either a bower.json file or a purs.json file for publishing packages. If it receives a purs.json file, then it will add the purescript- prefix to the name so as to mirror the Bower naming scheme.
• Pursuit reuses the Bower naming scheme supplied by purs publish, so everything is prefixed on Pursuit.

This is super messy! The registry has to perform some awkward processing so that things work out:

• We strip prefixes from packages when importing them from Bower, undoing the naming scheme. We don't strip the prefix if the package is published from a purs.json manifest.
• We have to re-add the prefixes when producing a resolutions file for publishing to Pursuit via purs publish so that the links work correctly. We don't add the prefix to the package manifest because the compiler already does that by default.

This can easily result in weird cases:

1. What happens if a user who hasn't followed all of this sees the prefixed names on Pursuit and on GitHub and decides to use a prefixed name in their purs.json manifest (since, after all, that seems to be what all the other packages are doing)? We will not strip off the prefix when registering and then a second prefix will be added when publishing to Pursuit.
2. What if we decide to ban the use of the prefix in package names for say 1 year so that people can switch over? Then, packages like purescript-language-cst-parser won't be able to use the prefix, even though in that case it totally makes sense: it's a parser for the PureScript language.

There's no clear answer for how to keep all of this tidy, but one idea I had is to reject packages that use the purescript- prefix by default, pinging the registry trustees — the user can opt-in to this explicitly and we can continue the pipeline, but by default we tell them the prefix is no longer used.

Regardless of everything else, we're gonna have to start putting a plan together for Pursuit, so that Pursuit itself no longer uses the prefix.