StaticType Rule Bugs

[MeirionHughes]

Please report any issues you find and I will try to collate and fix them as I can.

• Column offsets are always 0
• Order of Attributes in same element can break bindings to a locals
• Ancestor access doesn't check types i.e. $parent
• Capitalised filename should resolve (limited to Foo_ViewModel_ currently)
• Doesn't follow camel-case convention file <-> class
• Doesn't support Mapping ex: repeat.for="[id, customer] of customers"
• Complains it cannot find converter as field member
• Should add $index, $odd $even inside repeat.for as known variables
• context variables aren't overridden in nested controllers (same local name)
• Doesn't recognise interfaces.
• repeat.for doesn't work with interfaces imported from other files
• Template is not checked if the view model class name is different
• Traverses into private fields (should be warning).
• Doesn't support interpolation with attribute value
• Doesn't support Keyed Access
• Doesn't support negation operator on if.bind
• Bindable attributes passed to custom elements should be checked.
• Custom elements should be checked.
• Doesn't support Generics and use of Generic member types moved to feature
• Doesn't support Value Converters (different Type output) moved to feature

[zakjan]

repeat.for doesn't work with interfaces imported from other files

item.ts

export interface Item {}

page.ts

import {Item} from "./item";

export class PageViewModel {
    items: Item[];
}

page.html

<template>
    <template repeat.for="item of items">
        ${item}
    </template>
</template>

linter output:

[01:07:19] WARNING: cannot find 'item' in type 'PageViewModel' Ln 3 Col 0 /src/pages/page.html

[zakjan]

Template is not checked if the view model class name is different from the view and view model file names.

src/profiles/list.ts

export class ProfilesListViewModel {}

src/profiles/list.html

<template>
    ${item}
</template>

There is no linter issue found.

Also about your point "Doesn't follow camel-case convention file <-> class", I think no case convention should be enforced, the same basename of both files should be enough to pair them together.

[zakjan]

Custom elements should be checked.

item.ts

import {bindable} from "aurelia-templating";

export class ItemCustomElement {
    @bindable value: string;
}

item.html

<template>
    ${valu}
</template>

[zakjan]

Bindable attributes passed to custom elements should be checked.

item.ts

import {bindable} from "aurelia-templating";

export class ItemCustomElement {
    @bindable value: string;
}

item.html

<template>
    ${value}
</template>

page.ts

export class PageViewModel {
    value: number;
}

page.html

<template>
    <require from="./item"></require>

    <item value.bind="value"></item>
</template>

The same applies for value convertors, not only their output, but also their input should be checked.

[zakjan]

An idea to think about: allow only strings (and maybe numbers) in string interpolations?

export class PageViewModel {
    item: {name: string};
}

<template>
    <!-- fail -->
    ${item}
    <div title="Item: ${item}"></div>
    <!-- ok -->
    ${item.name}
    <div title="Item: ${item.name}"></div>
</template>

It could prevent unintentional implicit casting, for example to "[object Object]".

[atsu85]

I'd certainly use that.

[MeirionHughes]

...allow only strings (and maybe numbers) in string interpolations?

yeah that's good idea; could you lift that out as a feature request? I don't think its a bug per se.

[zakjan]

Yeah, of course. #44

[zakjan]

Boolean not operator reports error.

export class PageViewModel {
    value: string;
}

<template>
    <template if.bind="!value">
        ...
    </template>
</template>

linter output:

[20:48:18] WARNING: cannot find 'undefined' in type 'PageViewModel' Ln 2 Col 0 /src/pages/profiles/create/page.html

[MeirionHughes]

with regard to attribute ordering and using a local before it has been declared;
the issue is this:

<option model.bind = "employee.id" repeat.for="employee of employees"  > 

which can be fixed by using a more (in my view) logical ordering:

<option repeat.for="employee of employees"  model.bind = "employee.id" > 

given there are so many issues to work though, I won't be fixing this as yet.

[atsu85]

which can be fixed by using a more (in my view) logical ordering:

@EisenbergEffect, do I remember correctly, that different browsers gibe attributes in different order? If I remember correctly, then one browser gave it in the order it was written in source code, and some other browser gave it alphabetically? If so, then we shouldn't rely on the order of attributes, but rather set them on different elements?

[EisenbergEffect]

Yes. I don't think you can rely on attribute order. That's one reason why you can't have two template controllers on the same element and have to nest a template.

[EisenbergEffect]

But, the above example should work because the template controller overrides everything else and causes the scope to be created.

[atsu85]

@EisenbergEffect, I don't understand Your last message.

Do You mean, that the order of repeat.for and model.bind shouldn't matter, as

template controller overrides everything else and causes the scope to be created.

(that would contradict what @MeirionHughes mentioned earlier)
or do You mean, that in case repeat.for comes before model.bind it should work (as @MeirionHughes said)?

[EisenbergEffect]

The order should not matter. The presence of a template controller overrides everything else on the element. However, it makes more sense to have the template controller first.

[MeirionHughes]

Resolved; realized I could simply reorder them now that I pre-process into an AST.

[atsu85]

So this is the first feature, that modifies the output compared to the input?

[MeirionHughes]

Nope, nothing changes. The analysis code is basically one big state machine; I've simply re-ordered the attributes in the Syntax Tree, so the template controllers are examined first; presumably only the controllers add local variables. This means if you have <option model.bind = "employee.id" repeat.for="employee of employees" > in your code; it will correctly handle model.bind and know about employee.

The linter (with gulp) does nothing to the output.

[niieani]

Linting the navigation-skeleton with StaticType analysis shows the error:

WARNING in ./src/users.html
[9, 11]: cannot find 'image' in type 'Users'

 @ ./src/users.ts 95:0-31
 @ ./src/app.ts
 @ ./src/main.ts
 @ multi app

The source of this is blur-image.bind="image":

<canvas class="header-bg" width="250" height="70" blur-image.bind="image"></canvas>
<div class="avatar">
  <img src.bind="user.avatar_url" crossorigin ref="image"/>
</div>

The thing is, it's binding to the ref on the img below. Also, the whole thing is in a repeat.for="user of users" loop, so image property belongs on the IUser interface, not on the Users view-model.

[RomkeVdMeulen]

I'm getting false positives on vars added through ref like @niieani mentioned. Also a lot of false positives on things added through aurelia-validation's validation-errors attribute.

<form id="new" validation-errors="errors.bind: newErrors; controller.bind: newValidationController">
	<input type="text" value.bind="new.name & validate"/>
	<input type="submit"/>

	<p repeat.for="newError of newErrors" class="warning">
		${newError.error.message}
	</p>
</form>

gives:

[11:07:15] WARNING: cannot find 'newErrors' in type 'MyEditor' Ln 5

The simple binding validation-errors.bind="errors" also gives these false positives.