Ok, I completely take back what I said about TS and it's parser. I have investigated and custom linters and other things can be made.
So #4 is doable but the tool has to be written in TypeScript. See; https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API Mike On Mon, Jun 1, 2015 at 6:20 AM, Michael Schmalle <teotigraphix...@gmail.com> wrote: > On May 31, 2015 9:41 AM, "Michael Schmalle" <teotigraphix...@gmail.com> > wrote: > > > Now, I wish I had an answer of how to create a d.ts parser without using > > 100's of dev time hours. :) > > Do you have an idea of how the input vs. output would look like? Are you > planning on creating a d.as file which has all the class and function > definitions? > > Perhaps we can start with hand coding a simple example? I can help with > that. > > Thanks, > Om > > Well I know what we had in Randori and what Roland created for SWCs, that > is what I am using in my prototype but, we need a spec so as to not waste > time. > > This really needs to be thought about and documented first. If we have > what a class/interface(native defs or whatever) will look like, any > metadata used and how I write plugins to the emitter to generate from those > definitions. > > So my proposal is; > > 1. Write a simple spec for the d.as definition file/s. > 2. Create simple test files that utilize every aspect of our spec. > 3. Use the handwritten test files in FalconJX emitter tests to verify the > cross compile. > 4 Think about how we can translate IDL, builtin and d.ts definitions to > that spec once the spec is concrete and tested within the compiler and > working. > > Mike > >
