I quick look seems to indicate that these are coming from Jewel (which I'm not
using).
> On Jul 16, 2019, at 6:58 PM, Harbs <harbs.li...@gmail.com> wrote:
>
> These warnings look new:
>
> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> WARNING: externs/dialogPolyfill.js:15: WARNING - accessing name
> dialogPolyfill in externs has no effect. Perhaps you forgot to add a var
> keyword?
> dialogPolyfill = function() {
> ^^^^^^^^^^^^^^
>
> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> WARNING: externs/dialogPolyfill.js:15: WARNING - variable dialogPolyfill is
> undeclared
> dialogPolyfill = function() {
> ^^^^^^^^^^^^^^
>
> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> WARNING: externs/dialogPolyfill.js:23: WARNING - name dialogPolyfill is not
> defined in the externs.
> dialogPolyfill.registerDialog = function(dialog) {
> ^^^^^^^^^^^^^^
>
> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> WARNING: externs/hljs.js:19: WARNING - accessing name hljs in externs has no
> effect. Perhaps you forgot to add a var keyword?
> hljs = function() {
> ^^^^
>
> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> WARNING: externs/hljs.js:19: WARNING - variable hljs is undeclared
> hljs = function() {
> ^^^^
>
> Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager
> println
> WARNING: externs/hljs.js:27: WARNING - name hljs is not defined in the
> externs.
> hljs.highlightBlock = function(block) {
> ^^^^
>
> Any thoughts on this?
>
>> On Jul 15, 2019, at 10:32 PM, Josh Tynjala <joshtynj...@bowlerhat.dev> wrote:
>>
>> Hey folks,
>>
>> I just pushed some commits to royale-compiler and royale-asjs, and I wanted
>> to add a little explanation, and some possible troubleshooting advice if
>> anything seems to have broken in your apps.
>>
>> My work over the last week has been to fix an issue related to specifying
>> dependencies when compiling libraries for JS. As you probably know, the
>> compiler supports two options for adding libraries as dependencies,
>> library-path and external-library-path. The library-path compiler option
>> basically says "include all classes that I use from this SWC in the final
>> output". It's typically what you use when compiling an app that uses a
>> library. The external-library-path compiler option basically says "if I use
>> anything from this SWC, check that I'm using the types correctly, but don't
>> include any of classes from this SWC in the final output".
>>
>> If you're compiling an app, you typically use library-path for everything.
>> You use external-library-path only for dependencies like
>> playerglobal.swc/airglobal.swc in Flash or typedef SWCs in JS. Basically,
>> for an app project, external-library-path is for classes that are provided
>> natively by the Flash runtime or a web browser, like Chrome or Firefox.
>>
>> When compiling libraries, external-library-path is also used to prevent the
>> compiler from creating a "fat" library that stuffs in all of the
>> dependencies. Let's say that you have a library, A.swc. It provides some
>> core functionality that is needed by both B.swc and C.swc. When we compile
>> B.swc and C.swc, we don't want the classes from A.swc duplicated in both of
>> them. So we add A.swc to the external-library-path when compiling B.swc or
>> C.swc. Then, if you use those SWCs when compiling an app, you need to add
>> A.swc, B.swc, and C.swc to the library-path.
>>
>> To put that in Royale terms, A.swc is something like LanguageJS.swc or
>> CoreJS.swc. They're some of our lowest-level SWCs in the framework. B.swc
>> and C.swc are more like BasicJS.swc or JewelJS.swc, and they tend to share
>> multiple classes from the lower-level stuff.
>>
>> Up until now, library-path and external-library-path were a little quirky
>> when compiling to JS. It was related to the goog.provide() and
>> goog.require() calls that you might have seen in the generated JS. These
>> are from the module system that we use in Royale. The compiler didn't know
>> how to differentiate between classes that had goog.provide() and classes
>> that were typedefs for JS libraries. It treated everything on the
>> external-library-path as a typedef, and this led to missing goog.require()
>> calls in the generated JS. To work around this, when we specified
>> dependencies in our framework SWCs, we used library-path to ensure that
>> goog.require() would be used.
>>
>> This workaround of using library-path led to "fat" SWCs that contained all
>> of their dependencies. Low-level classes in SWCs like CoreJS were
>> duplicated in higher-level SWCs. This led to the compiler getting confused
>> about exactly where a class was defined.
>>
>> This has resulted in some minor issues here and there, but nothing too
>> major until recently. However, Harbs noticed the other day that it caused
>> the compiler to copy extra default CSS into apps from SWCs that you may not
>> have been using. So, you might build an app with the Basic components, but
>> you'd get extra CSS from Jewel or MaterialDesignLite. This could mess up
>> your app's styling pretty dramatically.
>>
>> I updated the compiler to better detect when a class needs goog.require()
>> and when it's a typedef. If that class comes from a SWC, the compiler knows
>> to check for an included file like, js/out/com/example/MyClass.js. If the
>> generated JS is there, goog.require() is necessary. If it's missing, it's
>> treated as a typedef class instead. If the class is an .as source file
>> instead, the compiler looks for the @externs asdoc tag to determine if it's
>> a typedef class (and everything else needs goog.require() instead).
>>
>> By the way, if we ever support other module systems, it shouldn't be too
>> difficult to extend this code to detect different SWC layouts for each
>> module system.
>>
>> If your project is an app, this change should not cause any problems.
>> You're probably using library-path and external-library-path correctly.
>>
>> If you have a project that is a library, you should check your compiler
>> options to see if you are using library-path and external-library-path
>> correctly. If your library depends on another library, you probably should
>> be using external-library-path because you don't want a "fat" SWC. In other
>> words, if you're using library-path in a library project, you probably need
>> to change that to external-library-path.
>>
>> If you have any custom typedef SWCs, you may want to recompile them. At one
>> point, the compiler had a bug where classes in typedef SWCs were being
>> incorrectly added to the "js/out" folder in the SWC, but that was
>> incorrect. They should have been placed in an "externs" folder instead. The
>> compiler handles this correctly now, but old typedef SWCs may look like
>> goog.require() SWCs instead. To be sure, you can open a SWC file in any
>> program that can read ZIP files, and you'll see the internal folder
>> structure. If a typedef SWC has a "js/out" folder, it's not going to work
>> properly.
>>
>> If you're working directly out of the royale-compiler and royale-asjs Git
>> repos, be sure to update and rebuild them both. The nightly builds should
>> be updated shortly.
>>
>> When you build any apps, be sure to clean first, just to be sure that you
>> have the latest JS files from the SWCs.
>>
>> If you run into any other problems with these changes, please let me know.
>> I'll get them fixed right away!
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC <https://bowlerhat.dev>
>
