feat: improve package structure

[deodad]

What is the feature you would like to implement?
A new package structure that better enables cross-environment support.

Proposal for package structure:

• @farcaster/core contains all isomorphic code (i.e. protobufs, utils, and builders, signers, types from @farcaster/js)
• @farcaster/node contains any node specific code (i.e. gRPC service definitions, client from @farcaster/js, re)

Not relevant at the moment but likely in the future:

• @farcaster/web that contains browser specific code (i.e. gRPC web client)

And eventually maybe even:

• @farcaster/react
• @farcaster/react-native

Each of the non core packages will depend on core and can re-export with export * from @farcaster/core (or a subset if we want to consider some exports of core internal) so developers only need to install, manage version, and import from one dependency.

Why is this feature important?
Developers should have the deal with installing, managing version of, and importing from as few packages as possible. Developers should not have to worry about whether the code they are running will be supported in the JS environment they are targeting.

Since tree shaking provides an automated way to eliminate unused code, it's not usually necessary to break out packages based on feature or functionality.

Since different JavaScript environments support different features, it's often necessary to write non-isomorphic code. In the FC case, given the state of grpc in the browser, it's likely necessary to write browser and node specific clients for interacting with hubs.

By breaking packages out by environment we create the least number of packages while avoiding confusion that arises when a package contains modules with varying environment support (e.g. module A is vanilla and works in browser + node, module B only works in node, module C only works in the browser).

Will the protocol spec need to be updated??
No

Additional context
There are a few related things that are preventing the farcaster packages from easily being used across environments:

• bug: @farcaster/js doesn't support browser environments #494
• feat: Move the protobuf RPC implementation into it's own package #473
• feat: improve tree shaking support #495

note: @farcaster/js could also work as a name for @farcaster/core since it's vanilla js, but I think core makes it more clear in the long run that its shared code and developers likely want to use one of the env specific packages

note: imo another valid reason to split up packages is to avoid awkward peer dependency requirements. For example, if there's a part of a package that contains framework specific code like react, express, etc, it should be broken out so consumers don't get peer dependency warnings for packages they aren't using

[sds]

Given we've split out the packages into @farcaster/core, @farcaster/hub-nodejs, and @farcaster/hub-web, is this issue good to close @deodad?

[deodad]

@sds yes closing