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