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> > > > >
