Understood. Thanks.
> On Sep 28, 2022, at 10:33 PM, Josh Tynjala <joshtynj...@bowlerhat.dev> wrote:
>
> Almost all of the values are true or false. If it says <int>, then you pass
> an integer value. If it says <string>, the available values should be
> documented on the options page.
>
> https://apache.github.io/royale-docs/linter/linter-options
>
> The *-name rules (-class-name, -field-name, etc.) are strictly true/false
> for now, but I'd like to expose a way to provide a custom regex pattern in
> the future. The defaults for all of the *-name options, when set to true,
> are basically just to enforce camel case. I should add the default regex
> patterns to the docs.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Sep 28, 2022 at 12:25 PM Harbs <harbs.li...@gmail.com> wrote:
>
>> Also, the values for some of the options are not very clear. How do we
>> discover possible values?
>>
>>> On Sep 28, 2022, at 10: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>
>>>
>>
>>
