Great tool. Perfectly would be integrated with VS Code. Harbs <harbs.li...@gmail.com> escreveu no dia quarta, 28/09/2022 à(s) 20:40:
> 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> > >>> > >> > >> > >