Create library project generators

[chiubaka]

(Copying from a comment on #39.)

Excitingly, starting work on this today. Types of libraries I expect to have:

• [x] Backend (Node.js-based) shared libraries (#39)
• [x] Common libraries to be shared across backend and frontend (#99)
• [x] Frontend shared libraries, which are probably the same thing
  • Possibly the same thing as common libraries to be shared across backend and frontend, since this should remain agnostic of view framework
• [ ] Frontend React shared libraries
• [ ] Frontend React Native shared libraries (#162)

Mostly the difference between these will be the base:

• Base library typings (e.g. those defined in tsconfig.json)
• Core installed packages (e.g. React will need react)
• Some core configuration (e.g. React will require some special tsconfig.json options)
• Testing support packages and configuration (e.g. React testing will need some special stuff)

[chiubaka]

Since a lot of the difference between these library packages is likely to be in tsconfig.json, I'm doing a quick comparison of typical working configurations for each project type.

Microsoft actually has a few starter project examples. Though they're archived and a few years old, I think they're probably still helpful here:

• TypeScript Node Starter
• TypeScript React Starter
• TypeScript React Native Starter

[chiubaka]

Some options that seem to be common across all projects:

• module is always set to commonjs
• moduleResolution is always set to node
• Seems safe to have a common target

Here are some notable differences:

• React sets "lib": ["dom"], since browser APIs should be present
• React and React Native set "jsx": "react"

Honestly, that's kind of it. I'm a bit surprised TBH.

[chiubaka]

Ah, this is a better and more up-to-date resource for common TS configurations: https://github.com/tsconfig/bases#centralized-recommendations-for-tsconfig-bases

[chiubaka]

Ok, target should potentially be changed based on the runtime environment, since this option changes how much of the code is down-leveled for compatibility. ES2015 (aka ES6) seems like the safest target for compatibility if building for the web. Otherwise, for environments like Node.js and React Native, compatibility is really more a function of the platform version than it is of the user's device or browser configuration, so matters less there.

[chiubaka]

Can potentially use the jsx: "react-native" option for React Native, as presumably FB's React Native compilers understand JSX and can do some of their own optimizations if this isn't down-leveled to something else.

[chiubaka]

Actually the differences between a backend, Node-compatible library, and a general, shareable library, are pretty minute. A Node-compatible library likely needs to list a node version as a peerDependency, and then set the TS target to something sensible for the version of Node I generate for (I think we're going to target Node v18).

[chiubaka]

Bumping this so that it doesn't appear stale for import into Linear.