In the discussion on #328 the consensus seems to be that people like type definitions. This moves toward generating types using jsdoc as suggested by @bollwyvl in that thread.

I don't have much Typescript experience so I would very much appreciate it if people could test them out. The types are available as CircleCI artifacts here:
https://3914-322074228-gh.circle-artifacts.com/0/root/repo/build/pyodide.d.ts

@bollwyvl said that

> types that aren't tested are probably worse than no types at all

If anyone could contribute tests, that would be very helpful (I don't know what they should look like). 

The main limitation I ran into with this approach is that Typescript supports Typescript types in jsdoc annotations but jsdoc does not. This means that if we want to automatically generate docs, we have to stick to the much more limited syntax that jsdoc supports. For example, `isPyProxy` should be typed `obj is PyProxy` but this approach does not allow that as far as I can tell. 
Some basic types. In the discussion on #328 the consensus seems to be that people like type definitions. This moves toward generating types using jsdoc as suggested by @bollwyvl in that thread.

I don't have much Typescript experience so I would very much appreciate it if people could test them out. The types are available as CircleCI artifacts here:
https://3914-322074228-gh.circle-artifacts.com/0/root/repo/build/pyodide.d.ts

@bollwyvl said that

> types that aren't tested are probably worse than no types at all

If anyone could contribute tests, that would be very helpful (I don't know what they should look like). 

The main limitation I ran into with this approach is that Typescript supports Typescript types in jsdoc annotations but jsdoc does not. This means that if we want to automatically generate docs, we have to stick to the much more limited syntax that jsdoc supports. For example, `isPyProxy` should be typed `obj is PyProxy` but this approach does not allow that as far as I can tell. 
The Pyodide runtime consists of the following components, sorted in terms of
initialization-time (or import-time) dependencies.

1. CPython
2. The py/_pyodide package which is a Python package with pure Python code
   avaiable in the inner stage of the Pyodide bootstrap process.
3. The core/pyodide code, implemented in a mix of C and Javascript, which embeds
   the CPython interpreter in an emscripten application. This relies on
   py/pyodide and js/pyodide at runtime. The final stage of initialization is to
   import py/pyodide.
4. The py/pyodide package which has Python code that is needed for the outer
   stage of the Pyodide bootstrap process. py/pyodide relies on core/pyodide at
   import time and relies on js/pyodide at runtime.
5. The js/pyodide package which defines the Javascript public API, sets up the
   process of loading the core/pyodide emscripten application + CPython
   interpreter, and then completes the bootstrap by injecting the js/pyodide
   API into the Python `sys.modules`.
6. The packages directory, which contains a large number of CPython packages
   built to run in Pyodide.

One of our long-term organizational goals is to carefully organize core/pyodide,
py/_pyodide, py/pyodide, and js/pyodide to clarify which functionality is not part of
runtime dependencies that define Pyodide's core behavior.

The Pyodide runtime consists of the following components, sorted in terms of
initialization-time (or import-time) dependencies.

1. CPython
2. The py/_pyodide package which is a Python package with pure Python code
   avaiable in the inner stage of the Pyodide bootstrap process.
3. The core/pyodide code, implemented in a mix of C and Javascript, which embeds
   the CPython interpreter in an emscripten application. This relies on
   py/pyodide and js/pyodide at runtime. The final stage of initialization is to
   import py/pyodide.
4. The py/pyodide package which has Python code that is needed for the outer
   stage of the Pyodide bootstrap process. py/pyodide relies on core/pyodide at
   import time and relies on js/pyodide at runtime.
5. The js/pyodide package which defines the Javascript public API, sets up the
   process of loading the core/pyodide emscripten application + CPython
   interpreter, and then completes the bootstrap by injecting the js/pyodide
   API into the Python `sys.modules`.
6. The packages directory, which contains a large number of CPython packages
   built to run in Pyodide.

One of our long-term organizational goals is to carefully organize core/pyodide,
py/_pyodide, py/pyodide, and js/pyodide to clarify which functionality is not part of
runtime dependencies that define Pyodide's core behavior.
