Re: Introducing aslint, a linter for ActionScript and MXML

[Hugo Ferreira]

Great tool.
Perfectly would be integrated with VS Code.

Harbs  escreveu no dia quarta, 28/09/2022 à(s) 20:40:

> Understood. Thanks.
>
> > On Sep 28, 2022, at 10:33 PM, Josh Tynjala 
> wrote:
> >
> > Almost all of the values are true or false. If it says , then you
> pass
> > an integer value. If it says , 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 
> >
> >
> > On Wed, Sep 28, 2022 at 12:25 PM Harbs  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  wrote:
> >>>
> >>> Do you have instructions on how to integrate the linter into VS Code?
> >>>
>  On Sep 28, 2022, at 12:14 AM, Josh Tynjala  >
> >> 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 
> >>>
> >>
> >>
>
>

Re: Introducing aslint, a linter for ActionScript and MXML

[Harbs]

Understood. Thanks.

> On Sep 28, 2022, at 10:33 PM, Josh Tynjala  wrote:
> 
> Almost all of the values are true or false. If it says , then you pass
> an integer value. If it says , 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 
> 
> 
> On Wed, Sep 28, 2022 at 12:25 PM Harbs  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  wrote:
>>> 
>>> Do you have instructions on how to integrate the linter into VS Code?
>>> 
 On Sep 28, 2022, at 12:14 AM, Josh Tynjala 
>> 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 
>>> 
>> 
>> 

Re: Introducing aslint, a linter for ActionScript and MXML

[Josh Tynjala]

Almost all of the values are true or false. If it says , then you pass
an integer value. If it says , 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 


On Wed, Sep 28, 2022 at 12:25 PM Harbs  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  wrote:
> >
> > Do you have instructions on how to integrate the linter into VS Code?
> >
> >> On Sep 28, 2022, at 12:14 AM, Josh Tynjala 
> 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 
> >
>
>

Re: Introducing aslint, a linter for ActionScript and MXML

[Harbs]

Gotcha.

> On Sep 28, 2022, at 10:28 PM, Josh Tynjala  wrote:
> 
> 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 
> 
> 
> On Wed, Sep 28, 2022 at 12:18 PM Harbs  wrote:
> 
>> Do you have instructions on how to integrate the linter into VS Code?
>> 
>>> On Sep 28, 2022, at 12:14 AM, Josh Tynjala 
>> 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 
>> 
>> 

Re: Introducing aslint, a linter for ActionScript and MXML

[Josh Tynjala]

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 


On Wed, Sep 28, 2022 at 12:18 PM Harbs  wrote:

> Do you have instructions on how to integrate the linter into VS Code?
>
> > On Sep 28, 2022, at 12:14 AM, Josh Tynjala 
> 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 
>
>

Re: Introducing aslint, a linter for ActionScript and MXML

[Harbs]

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  wrote:
> 
> Do you have instructions on how to integrate the linter into VS Code?
> 
>> On Sep 28, 2022, at 12:14 AM, Josh Tynjala  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 
> 

Re: Introducing aslint, a linter for ActionScript and MXML

[Harbs]

Do you have instructions on how to integrate the linter into VS Code?

> On Sep 28, 2022, at 12:14 AM, Josh Tynjala  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 

Introducing aslint, a linter for ActionScript and MXML

[Josh Tynjala]

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