chore: add ink and react peer dependencies

[pieh]

In some cases right now packages might be installed weirdly in node_modules - especially if you end up in 2 separate instances of react (1 for frontend code and 1 for terminal utility using ink). This seems to give hint to package managers (tested with yarn and npm on how to structure packages in node_modules).

Some background on this - in https://github.com/gatsbyjs/gatsby we want to move our CLI to use ink, but because primarly gatsby is tool for frontend where user specify react version (it's not bundled with gatsby). We might end up with 2 react instances if user is using react version lower than 16.8.0 (which is specified is minimal peer dependency in ink ( https://github.com/vadimdemedes/ink/blob/master/package.json#L84-L86 ). Because of that ink component packages might end up being hoisted to top level node_modules but ink and react itself might be in node_modules/gatsby-cli/node_modules, which cause "Module not found" errors from ink-spinner when it tries to import from those modules.

I was testing this before with forked/scoped of ink-spinner ( https://unpkg.com/@pieh/[email protected]/package.json ) and it seems to solve issues we saw, when react@<16.8.0 was used.

I might not sure on exact versions of ink and react to chose for peer dependencies - so I choose lowest ink and same react as in devDeps.

[pieh]

Is the failed test a flake? It didn't happen locally, and also my changes to add peerDependencies shouldn't affect those I think?

[vadimdemedes]

Thanks for this PR! It's weird that tests started failing, I guess one of my recent changes to Ink could've caused it. Going to merge this anyway and fix tests afterwards.

[vadimdemedes]

Couldn't fix the tests on CI yet (they pass locally), so I did a release anyway - 3.0.1.