I agree, it will be great to get JS API code-intelligence.
Just out of curiosity, what did you have to change? One work item for the
future is to merge the "JS" SWC into the "SWF" SWC so there is only one
SWC per library instead of the current pair like Core.SWC and CoreJS.swc.
I'm trying to assess the impact of doing so. We can certainly teach the
compiler to pick different classes based on the current -target, but right
now for FB, all it knows is that one set of SWCs or the other is on the
library path. If we merge the SWCS, there is no other way to tell the
compiler which APIs to use by default, and I'm not sure I can control that
from outside FB.
Maybe just the Maven artifacts will be merged and we'll keep the pairs of
SWCs for IDEs.
Thoughts?
-Alex
On 7/6/17, 4:12 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>Okay, I figured out how to make VSCode switch to JS APIs instead of SWF
>APIs for completion and things. In the next version of the extension, when
>the targets compiler option is specified in asconfig.json, and the first
>value isn't "SWF", the extension will offer JS APIs. That includes giving
>you access to native browser APIs instead of Flash Player APIs. That's
>going to be a really nice change, I think. Thanks for pointing out this
>issue!
>
>- Josh
>
>On Thu, Jul 6, 2017 at 2:35 PM, Josh Tynjala <joshtynj...@gmail.com>
>wrote:
>
>> > The js-output-type, library-path and external-library-path options are
>> probably not needed
>>
>> I would get rid of -js-output-type. I assume that -targets takes
>> precedence, but just to be safe, you shouldn't use both.
>>-js-output-type is
>> necessary for 0.7.0, but switch entirely to -targets with 0.8.0.
>>
>> > It would be nice to have full support for the new compiler options
>>
>> html-template, html-output-filename, js-compiler-option,
>> js-external-library-path, js-library-path, swf-external-library-path,
>> swf-library-path, and remove-circulars should all work in the
>> compilerOptions field if you're using the latest vscode-nextgenas 0.4.4
>>and
>> asconfigc 0.5.1. I just updated asconfigc to support these options last
>> week, and I haven't made an official announcement yet, so you might have
>> missed that one.
>>
>> I think there may be one or two you'll still need to put into
>> additionalOptions, but you should be able to switch over most of them.
>>
>> > 1. I’m getting “problems” even for files which are not used in my
>> project and are not open.
>>
>> This is something I'm aware of in VSCode. The compiler seems to greedily
>> load everything that exists in a source path, even if you don't actually
>> use it. Personally I like this, but even if I were to make it an option
>> somehow, I'm not aware of a way to stop the compiler from working that
>>way
>> either.
>>
>> > 2. I’m getting lots of errors which are specific to SWF-only output:
>>
>> I just glanced through the part of VSCode that passes options to the
>> compiler for code intelligence (different from the way that asconfigc
>>runs
>> the compiler to build), and I don't think I'm actually using the value
>>of
>> -targets. It's probably defaulting to SWF. I'll play around with that to
>> see if I can improve things when -targets is specifically JSFlex.
>>
>> > a. I’m not getting JS specific classes recognized.
>>
>> Just to be clear, are you referring to DOM classes like
>>HTMLButtonElement
>> and other browser APIs here? I just want to be sure so that I test the
>> right thing when I make changes.
>>
>> - Josh
>>
>> On Thu, Jul 6, 2017 at 2:16 PM, Harbs <harbs.li...@gmail.com> wrote:
>>
>>> Since updating to “dual”has been reporting lots of errors. When I
>>>build,
>>> both the debug and release builds build correctly, but the PROBLEMS
>>>window
>>> and the live code hinting report lots of (non) issues. I’m not sure
>>>what
>>> the source of the errors are, but here are the details:
>>>
>>> I’ve tried a few variations of the asconfig file, but here’s what I
>>> currently have:
>>> {
>>> "config": "flex",
>>> "compilerOptions": {
>>> "debug": true,
>>> "js-output-type": "flexjs",
>>> "targets": ["JSFlex"],
>>> "source-map": false,
>>> "library-path": [
>>> "lib"
>>> ],
>>> "external-library-path": [
>>> "typedefs"
>>> ]
>>> },
>>> "copySourcePathAssets": true,
>>> "additionalOptions": "-remove-circulars
>>>-js-output-optimization=skipAsCoercions
>>> -html-template=src/resources/mdl-js-index-template.html
>>> -js-external-library-path+=typedefs -js-library-path+=lib",
>>> "files":
>>> [
>>> "src/PortedPrintUI.mxml"
>>> ]
>>> }
>>>
>>> The js-output-type, library-path and external-library-path options are
>>> probably not needed, but they don’t seem to adversely effect the
>>>builds.
>>> (It would be nice to have full support for the new compiler options.)
>>>
>>> Problems:
>>> 1. I’m getting “problems” even for files which are not used in my
>>>project
>>> and are not open.
>>> 2. I’m getting lots of errors which are specific to SWF-only output:
>>> a. I’m not getting JS specific classes recognized.
>>> b. I’m getting lots of incompatible overrides (to Flash methods)
>>> c. I’m getting overriding function not marked for override errors on
>>> functions that are implemented in flash (i.e. public function get
>>> scaleX():Number)
>>> d. conflicts between variables and Flash getters.
>>> e. etc...
>>>
>>> Thanks,
>>> Harbs
>>
>>
>>
