Hey has anyone tried the auto externs generator lately? I get a failed response for a certain file and I'm unsure why: http://www.dotnetwise.com/Code/Externs/index.html

I'm trying to generate externs for this file: https://raw.githubusercontent.com/Tonejs/Tone.js/master/build/Tone.js

I feel like I'm missing something

I'm wary of manually creating the externs simply due to the work (Tonejs is ~ 20k lines) and find out its not even compatible, but referencing this closed PR https://github.com/google/closure-compiler/pull/1048 (by a core cljs contributor) it looks like AMD modules are at the very least, Google Closure compatible. Might just be the auto-externs generator doesn't cover all usage cases, and I'll have to just manually do these externs 😞

@mikebelanger Did you try this generator: http://michaelmclellan.me/javascript-externs-generator/?

And even if you need to create externs manually, you don't need to go through the code, it is easier to just go through API docs: https://tonejs.github.io/docs/#Split

@juhoteperi yes, I had to use the -> trick with that, and it just repeatedly hanged (using FF)

@juhoteperi you mean just list off each module in the API?

Pretty much yeah

Each class & their methods

There is also some change that Closure module processing world work in this case.

Tone.js has a lot of type annotations, do you think those would be useful to Closure compiler?

No

Not at least if you are using the lib as foreign-lib, with the concatenated file

Sorry, I don't know what you mean by concatenated file, like the minified file?

Yes

concatenated file = all source in one file, minified = all source in one file + minified

@juhoteperi Ah I see, thanks. I might just use the Tone.js source (un-minified, but concatenated), and delete everything in the blocks, and save it as an extern. There's a lot of prototypes, objects, etc.

That is one way.

But just keep in mind that only the public API matters, the functions you could call from Cljs

There are lots of internal functions that don't need to be present in the extern

@juhoteperi true, oh I see what you mean -- because if I cross-reference the API to figure out which functions are public vs. which aren't, I'm probably going to spend as much time doing that as just listing them off in a new file anyways.

Btw. they have TypeScript annotations which also lists the public API: https://github.com/Tonejs/TypeScript/blob/master/Tone.d.ts

@juhoteperi oh cool, good find! Translating that doesn't look like it would take nearly as long

@juhoteperi well thanks a lot for your help, its going to make my life much easier

Ok, I'm just writing them up, and seeing there's lots of methods inside of other prototype functions. Seeing that using this in externs is strongly discouraged, would the best bet be writing the full method name (ie Tone.Foo.prototype.bar = function() {})?

At least, it appears Google Closure doesn't like this due to its context-dependent reference http://stackoverflow.com/questions/13109358/javascript-this-keyword-and-closure-compiler-warnings

Full name is fine

alright thanks