Category #1 is when someone intends to combine code from a SWC into another SWC to create one mega-swc, maybe to reduce the number of SWCs or, back in the day, to create one RSL instead of two. I don't think Royale should ever need to do this.
Category #2 is the other AS classes from other SWCs you need. As you mentioned Jewel.SWC uses Basic org.apache.royale.states.States (from Core.swc or Basic.swc). Category #3 is definitions that are not in Royale code. For SWF versions of SWCs, it is everything in playerglobal/airglobal. So Sprite, DisplayObject, other flash.*.* packages. For JS versions of SWCs it is HTMLElement and other stuff in js.swc or other typedefs. If you are suggesting that somehow the compiler will know that some SWCs on the external-library-path are typedefs vs a framework class from Core.swc or Basic.swc, that might be possible, but I don't know how efficient that will be (or accurate) to determine that, plus portions of the compiler have a test for "isExternal()" that we'd have to make sure we get right. That's why I suggest that we add some new option that lists classes that shouldn't be linked into library.swf without marking them "isExternal()". There is already a similar option that does mark classes as "isExternal()" that we might be able to leverage. HTH, -Alex On 7/9/19, 3:43 PM, "Josh Tynjala" <[email protected]> wrote: > 3) code that should not be in the output SWC that doesn't support goog.require/goog.provide Is there anything other than a typedef SWC that could be classified as #3? It seems like we have an extra category that doesn't exist in practice, but we're giving it priority over a category that is more common. Not just with framework SWCs either. Third-party SWCs that include custom components would need to set the framework SWCs on the external-library-path too. -- Josh Tynjala Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Ce8d3fd5407a241169b3708d704bed6ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983090037408433&sdata=ZLh%2BhjW0JHwUJiGJC3%2B5imtgGoFDWFxI1rNvFnZoYGY%3D&reserved=0> On Tue, Jul 9, 2019 at 3:33 PM Alex Harui <[email protected]> wrote: > I'm not sure why Jewel CSS is winding up in non-Jewel apps, but the issue > of whether SWC dependencies should be on the library-path or > external-library-path isn't so much as a bug (functionality that isn't > working as expected) but rather, a problem we've had "forever". > > With only -library-path and -external-library-path options, that is only > two categories to categorize: > > 1) code from another library you want included in the output SWC > 2) code that should not be in the output SWC but supports > goog.require/goog.provide > 3) code that should not be in the output SWC that doesn't support > goog.require/goog.provide > > When we build the framework, we rarely ever want #1. So we've been using > -library-path for #2 and -external-library-path to be #3 and somehow got > this far by ignoring the fact that code that shouldn't be duplicated in the > SWCs are. I think it has been like that "forever", so no idea why it is > breaking now unless folks are using the JS versions of the SWCs more these > days. > > I didn't think the duplication was causing problems but since it > apparently is, I think the compiler would need a way to know to exclude > certain classes from the output SWF. I think there is already an -externs > option but that requires listing every class which would be painful to > administrate. And I think that might re-categorize the class as being on > the -external-library-path which we don't want either. So maybe a new > compiler option to exclude all classes from a SWC in the output library.swf > is best. > > HTH, > -Alex > > On 7/9/19, 3:06 PM, "Josh Tynjala" <[email protected]> wrote: > > I have confirmed that these SWCs are defined on the library-path in the > compile-js-config.xml used to build JewelJS.swc. Instead, it should be > using the external-library-path or js-external-library-path. > > In compile-swf-config.xml for Jewel.swc, the dependencies are correctly > defined on external-library-path so that they aren't included in > Jewel.swc. > > Unfortunately, my initial attempts to use external-library-path or > js-external-library-path are running into issues. I worry that it may > be > related to this comment in compile-js-config.xml where the SWCs were > added > to the library-path: > > <!-- asjscompc won't 'link' these classes in, but will list their > requires > if these swcs are on the external-library-path then their requires > will not be listed --> > > I could be wrong, but I interpret this comment to mean that > goog.require() > is not added if something is on the external-library-path. That sounds > like > a bug in the compiler, and this was more of a workaround than the > correct > way to fix things. > > -- > Josh Tynjala > Bowler Hat LLC < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Ce8d3fd5407a241169b3708d704bed6ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983090037418422&sdata=Fe70Ma1MFoARKGr%2FSi2zgEhNRgkpn3sQDoPY6eN5QmI%3D&reserved=0 > > > > > On Tue, Jul 9, 2019 at 2:35 PM Josh Tynjala <[email protected] > > > wrote: > > > It looks like JewelJS.swc includes some classes in the SWC that > probably > > shouldn't be there. One example (but there are many more): > > org.apache.royale.states.State. > > > > These are core classes that should be from dependencies, and I > suspect > > that something might be on the library-path instead of the > > external-library-path. Because the compiler found the class in > JewelJS.swc, > > it assumes that it needs defaults.css from JewelJS.swc too. > > > > To try to reproduce this issue, I created a sample app that uses only > > Basic components. I'm seeing that the compiler is trying to use > > defaults.css from Basic, Express, Jewel, and MaterialDesignLite. > > > > I'll take a look at the compiler options for some of the other SWCs > to see > > if anything catches my eye. > > > > -- > > Josh Tynjala > > Bowler Hat LLC < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Ce8d3fd5407a241169b3708d704bed6ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983090037418422&sdata=Fe70Ma1MFoARKGr%2FSi2zgEhNRgkpn3sQDoPY6eN5QmI%3D&reserved=0 > > > > > > > > On Tue, Jul 9, 2019 at 3:21 AM Harbs <[email protected]> wrote: > > > >> I have no jewel components in my app, but I’m suddenly seeing TONS > of > >> jewel css in my app. > >> > >> Similarly, I’m seeing Basic CSS (such as Button) which did not used > to be > >> included (and is messing up the visuals in my app). > >> > >> Has something changed with the logic which includes CSS? > >> > >> Harbs > > > > > > >
