Gotcha.
> On Sep 28, 2022, at 10:28 PM, Josh Tynjala <joshtynj...@bowlerhat.dev> wrote:
>
> It's currently possible to run it on the command line only. You could
> either open a terminal and run the aslint command manually, or you could
> add a custom task in your workspace's tasks.json file. Something like this:
>
> {
> "label": "aslint",
> "type": "shell",
> "command": "/path/to/aslint",
> "args": [
> "src"
> ]
> }
>
> If you want to customize the rules, you can either add more args to the
> task, or you can create an aslint-config.xml at the workspace root.
>
> You'll need to add a problem matcher to the task to get issues to show up
> in the Problems view. Otherwise, they'll appear in the terminal output
> only. Check the docs for how to do that.
>
> Ideally, I'd like to add deeper integration with vscode-as3mxml. Linter
> issues should automatically show up in the Problems view as you type (or
> maybe when you save a file). I haven't had time to dig into that yet.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Sep 28, 2022 at 12:18 PM Harbs <harbs.li...@gmail.com> wrote:
>
>> Do you have instructions on how to integrate the linter into VS Code?
>>
>>> On Sep 28, 2022, at 12:14 AM, Josh Tynjala <joshtynj...@bowlerhat.dev>
>> wrote:
>>>
>>> Hey folks,
>>>
>>> I recently committed a new tool to the royale-compiler repository. It's
>>> called aslint, and it is a linter to find common issues in .as and .mxml
>>> files.
>>>
>>> You can find more information about aslint in the documentation that I
>>> created:
>>>
>>> https://apache.github.io/royale-docs/linter
>>>
>>> This new linter includes a number of rules. Some rules are enabled by
>>> default. Other rules are more opinionated, and they may not be right for
>>> everyone, so you need to opt into them.
>>>
>>> We can certainly add more rules in the future, but let's be mindful about
>>> which are enabled by default, and which are opt-in. The list of defaults
>>> should be small — with a focus on code issues that are most likely to
>> cause
>>> actual bugs. Let's strive to avoid enabling formatting rules by default
>>> (where braces are placed, spacing around operators, tabs/indents, etc.).
>>> Everyone has their own opinions on formatting, and people will avoid
>> using
>>> a linter if they don't agree with the formatting it wants to enforce. We
>>> can include formatting rules, of course, but we should always make them
>>> opt-in.
>>>
>>> All available command line options, including options to enable or
>> disable
>>> specific rules, are documented here:
>>>
>>> https://apache.github.io/royale-docs/linter/linter-options
>>>
>>> Additionally, you can create an aslint-config.xml file containing the
>>> options you'd like configured for a specific project, and it will be
>> loaded
>>> by the tool automatically.
>>>
>>> https://apache.github.io/royale-docs/linter/aslint-config-file
>>>
>>> The architecture of aslint is very similar to the asformat tool that I
>>> added a while back. It loads one or more files, and it uses the compiler
>> to
>>> generate data structures to represent the code in memory. In asformat, it
>>> generates a simple token stream with the compiler, which is enough to
>>> recognize keywords, operators, and other basic parts of the code. In
>>> aslint, it generates a token stream the same way, but it also generates
>> an
>>> Abstract Syntax Tree (AST), which allows for a more detailed analysis of
>>> the code.
>>>
>>> Let me know if you run into any issues. Thanks!
>>>
>>> --
>>> Josh Tynjala
>>> Bowler Hat LLC <https://bowlerhat.dev>
>>
>>
