You know, I just realized... we should start adding the "native" modifier to ActionScript classes in typedef SWCs. Typedef SWCs serve the same purpose as playerglobal/airglobal SWCs, which are also compiled as "native". They all define APIs that will be available at run-time and the SWC should only be used for checking types and things at compile-time.
IDefinition has an isNative() method that tells you if a class was marked with the "native" keyword. We would use that instead of library-path/external-library-path to determine whether goog.require() is needed for a particular class. This would keep library-path/external-library-path working as they always have, without affecting goog.require(). I think I actually suggested using the "native" keyword for typedefs a very long time ago. I think you said that externc or the JS emitter didn't handle it properly. Since I wasn't very familiar with the compiler code at the time, I didn't think I could fix it, so I dropped the idea. This is what was missing. We were ignoring a feature of the language that was meant for exactly this situation. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Tue, Jul 9, 2019 at 4:00 PM Alex Harui <[email protected]> wrote: > 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 > > > > > > > > > > > > > > >
