style: Apply prettier config consistently

[kriskowal]

This change regularizes the use of the prettier config block in package.json, demonstrating that all packages already lint properly with this configuration.

This also sets regularizes lint in dapp-svelte-wallet/api.

[kriskowal]

@katelynsills This change brings Agoric SDK into alignment with the companion change endojs/endo#538 but is almost a noöp for style. Welcome feedback would be to abandon this and use .prettierrc in SES-shim instead. Though, I think you previously expressed favor for doing more in package.json. Either way, I think the next level of polish would be to make an @agoric/dev dependency that in turn draws upon @agoric/eslint-config and the other common tooling like ava and rollup, and a bin that we can use to incrementally rescaffold package.json to bring these into alignment, possibly as a postinstall hook.

[katelynsills]

Looks good to me! Did you happen to try Michael's solution of including a .prettierrc at the top level?

[katelynsills]

huh do you know why we have so many new entries in the lock file? Not important, but I'm just curious. I would have thought this would be the same or a reduction.

[kriskowal]

This does suggest something went wrong. I’ll look into it.

[kriskowal]

Looks good to me! Did you happen to try Michael's solution of including a .prettierrc at the top level?

I did not. It would probably work, as it did for .eslintrc in the SES-shim. Decided not to go that way with .eslintrc since we can’t package that solution. We can’t package prettier anyway, so it might make sense to go a different way.

I think that we need a prettier config block that is redundant with the eslint config, when eslint is driving prettier, is itself a bug and I’m wondering whether we’ll need any prettier config at all after we upgrade.

[kriskowal]

My best guess for the reason for the lockfile growth is that the eslint dependencies were previously only devDependencies in multiple packages. They do have to be promoted for this arrangement, since the devDependencies of devDependencies don’t get entrained.