> 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://bowlerhat.dev> 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%7Cc10e9c73a5954c16e96a08d704b9abf6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983067811352669&sdata=ZE1Kb6B418%2FEw7MuGPdmCjKsHKE5wMspjavvDVqRjyw%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%7Cc10e9c73a5954c16e96a08d704b9abf6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983067811352669&sdata=ZE1Kb6B418%2FEw7MuGPdmCjKsHKE5wMspjavvDVqRjyw%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 > > > > > > >
