Commit a2ee3cc

- **Accidental exports:** You meant for your `DrawHelper` class to be kept internal, but one day you realize it's a package export. When you try to remove it, consumers complain that they are using it. How do we avoid this in the future?

- **Alpha/Beta graduation:** You want to release previews of new APIs that are not ready for prime time yet. But if you did a major SemVer bump every time you change these definitions, the villagers would be after you with torches and pitchforks! A better approach is to designate certain classes/members as **alpha** quality, then promote them to **beta** and finally to **public** when they're mature. But how to indicate this to your consumers? (And how to detect scoping mistakes? A **public** function should never return a **beta** result.)

- **\*.d.ts rollup:** You webpacked your library into a nice **\*.js** bundle file -- so why are you distributing your typings as a messy tree of **lib/\*.d.ts** files full of private definitions? Let's consolidate them into a tidy **\*.d.ts** rollup file. If you publish internal/beta/public releases, a semantic analyzer can trim the **\*.d.ts** rollup according to each release type. Developers working on a production project don't want to see a bunch of **internal** and **beta** members in their VS Code IntelliSense!

- **Online documentation:** You have faithfully annotated each TypeScript member with nice [JSDoc](http://usejsdoc.org/) descriptions. Now that your library is published, you should probably set up [a nicely formatted](https://docs.microsoft.com/en-us/javascript/api/sp-http) API reference. Which tool should we use to generate that? (What!? There aren't any good ones!?)

- Generate \*.d.ts rollups

- Output API documentation in a portable format that's easy to integrate with your publishing pipeline