Make the initial configuration `access` property `public` by default

[remorses]

Affected Packages

Problem

Most people will try to use changeset with a public package for the first time, making the config generated by changeset init with restricted access as default will make the initial setup more difficult

In my case i got weird npm errors at time of publishing because i didn't notice the config has access restricted by default (errors like EUNSCOPED Can't restrict access to unscoped packages)

Proposed solution

I think the default config should have "access": "public" as default

[Andarist]

@Noviny @mitchellhamilton any particular reason behind choosing the "access": "restricted" as the default?

[didoesdigital]

Perhaps it is enough to give people a heads up. For example, under the init step of the CLI README add a note like:

To publish your packages publicly to NPM, you'll need to edit .changeset/config.json and change "access": "restricted", to "access": "public",. Read more about access in config file options.

[Andarist]

@didoesdigital documentation PRs are always welcome

[ianstormtaylor]

+1 to this default making no sense. Anyone who tries to use this for an open-source project will run into this error on their first attempt currently.

[Andarist]

Well, this matches the npm's default so I think it makes sense. Also not publishing a public package is just a minor obstacle that gets fixed pretty quickly - OTOH publishing a private package by accident might be a big deal.

We could make this a required property of the config in the future though - that way it would be more obvious for people that they should tweak it. WDYT @ianstormtaylor ?

[ianstormtaylor]

@Andarist since it seems like this only applies to scoped packages, maybe unscoped packages could ignore it entirely and not fail by default? This would make it easier for non-scoped users who don't ever think about "access" and wouldn't know to change that setting. And for people who have scoped packages it's an important setting like you mentioned, so a failure first is okay.

Side note, seems like a weird decision for npm to have tied it to each publish instead of tying it to the package itself.

[nickherious]

I ran into this problem for my first time use, searched google and this came up.