If these are regular comments, then they won't appear in our d.ts files.
But, now we are relying on an external d.ts bundler to produce our final
merged, so they need to be present in the "input" d.ts files, meaning
they have to be JSDoc comments.
These comments only work today because all of our builds load their TS
files from scratch, so they see the actual source files and their
non-JSDoc comments.
The comments also need to be attached to a declaration, not floating,
otherwise they won't be used by api-extractor, so move them if needed.
This step converts as many explicit accesses as possible in favor of direct imports from the modules in which things were declared. This restores the code (as much as possible) back to how it looked originally before the explicitify step, e.g. instead of "ts.Node" and "ts.Symbol", we have just "Node" and "Symbol".
This step converts each file into an exported module by hoisting the namespace bodies into the global scope and transferring internal markers down onto declarations as needed.
The namespaces are reconstructed as "barrel"-style modules, which are identical to the old namespace objects in structure. These reconstructed namespaces are then imported in the newly module-ified files, making existing expressions like "ts." valid.
* Remove redundant checker functions, use patterns more friendly to modules
* Also use a helper for localizedDiagnosticMessages
* Move types into same file as consts
* Accept slightly changed api baseline
* Whitespace!
* Check to make sure default npm exists at path before trying to use it
**Bug**
If the typings installer is run under a copy of node that does not include npm—but on a machine that does have npm installed—it will incorrectly try to use the npm that does not exist next to its running version of node
**Fix**
Make sure that we check that npm we select exists before trying to use it as the default. Otherwise, fall back to using plain old `npm`
* Add command line flag to gate new behavior
* Fix missing semicolon
