Thanks. I'm investigating.

I've figured out that the Maven build is still using library-path (or
js-library-path) instead of external-library-path (or
js-external-library-path) when building the framework SWCs.

If I run "mvn clean install" in frameworks/projects/Jewel, I can see that a
target/compile-js-config.xml file is created, and it's using
js-library-path for framework SWCs. I'm still figuring out where this
config file is coming from and how to change it.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Tue, Jul 16, 2019 at 9:00 AM Piotr Zarzycki <piotrzarzyck...@gmail.com>
wrote:

> Josh,
>
> It looks like something is happened actually. Latest build on server
> failed, but was able to build all examples and TourDeJewel is not running
> [1]
>
> [1]
>
> https://builds.apache.org/job/Royale-asjs/1956/artifact/examples/royale/TourDeJewel/target/javascript/bin/js-debug/index.html
>
> Thanks,
> Piotr
>
> wt., 16 lip 2019 o 17:58 Harbs <harbs.li...@gmail.com> napisaƂ(a):
>
> > 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>
> >
> >
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>

Reply via email to