Refactor package structures to "client" + "server"

[Josh-Cena]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Motivation

All packages should have a client and a server folder. Here's a good model: https://github.com/cmfcmf/docusaurus-search-local/tree/master/src

What's wrong with the current setup?

Currently, a plugin's server code is at the root of src/ while most client code is in src/theme/. It's hard to tell which file belongs to Node and which is Webpack, which sometimes leads to server code ending up in client. For most packages the only client folder is theme; but for plugin-content-docs, for example, it also includes client.

Moreover, this makes TS transpilation hard. Had we started with a clear client-server biclassification, a lot of the trouble in #5612 can be avoided. We can simply transpile the two folders with different TSConfigs without worrying about one's output overwriting another. As we go on to work on #5612, we can just watch changes in the client folder, because hot-reloading the server code isn't going to update the website anyways.

What does it take to separate the two folders?

Almost nothing—just move what's currently in src/ to src/server/ and what's in src/theme/ to src/client/theme/. We can also use two tsconfig files in src/server/ and src/client/ with different types (we shouldn't have @types/node in client, for example), and different .eslintconfig.

Self-service

• I'd be willing to do some initial work on this proposal myself.

[slorber]

Agree we should do this, but probably not right now :)

We should also look into using exports because a plugin does not have a single entry point and in practice could also expose some client-side or server-side utils/APIs (the docs plugin does this, but in a quite messy way)

https://nodejs.org/api/packages.html#package-entry-points

[Josh-Cena]

We have different exports for reading-time: https://github.com/ngryman/reading-time/blob/dbe1d26d14892ee991a1799ca576df4de2824bf7/package.json#L5-L6

I think the general direction is we should try to eliminate all import xxx from x/lib/core/... kind of import. Since we have @theme/ aliases the client export is probably fine