On 12/2/16, 9:59 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:
>> >> >> I'm not sure we have a way to manage random JS files in the tool chain. >> JS files that use goog.provide can be included in a SWC and will be >>copied >> to the output folder by the compiler. So you may want to consider >>adding >> some sort of goog.provide to that file. > > >interesting. Some example already set to see how to do this? something >already in place to take as example an make my own ? We've not done this before, AFAIK. > > >> Otherwise, folks will have to >> manage it like any other asset. The tool chain does support links to >> random JS files via the inject_html directive. >> > >so, gol.provide will be for bundle in swc...while inject_html will put the >line in my index.html right? Yep. > > >> >> Also, if this code can be called by other code in JS files being sent to >> the Google Closure Compiler for minification/optimization, then an >>externs >> file for this file will need to be generated. >> > >I think this is not the case. MDL talks about it as a "companion", so they >provide some class css and maybe js, but they suppose the dialog-polyfill >is setup and in place. Right now externs are an obscure concept to me, >where I could read about it and whats behind? Google Closure Compiler docs contain information about externs. Basically it is a file format that describes which APIs should not be renamed by the minifier because the files are loaded externally. If the JS is not called from any JS code we've written or compiled then you don't need an externs. Although it makes me wonder how any of that code gets called. IMO, linking to it is simpler. Folks can always download it and integrate it into their html if they don't want to rely on the CDN. -Alex
