Re: Introducing aslint, a linter for ActionScript and MXML

[Hugo Ferreira <hf...@gmail.com>]

Great tool.
Perfectly would be integrated with VS Code.

Harbs <ha...@gmail.com> escreveu no dia quarta, 28/09/2022 à(s) 20:40:

> Understood. Thanks.
>
> > On Sep 28, 2022, at 10:33 PM, Josh Tynjala <jo...@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 <ha...@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 <ha...@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 <joshtynjala@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>
> >>>
> >>
> >>
>
>