Some jshint issued errors

[adriatic]

Reporting these just to get a short break from aucs work 😄 - and because I do care that vscode is happy. If you agree, I will gladly create a PR for all such cases.

[adriatic]

The suggestion to add the jshint.rc file

{
  "jshint.options": {
    "esversion": 6
  }
}

This would be a bad approach, because Aurelia ships with its definition file for eslint (issue 178) - which really does not address any of the jshint errors shown on the screenshot above.

A lot better approach is to suggest adding the setting "jshint.enable: false" in the user settings section of File: properties:

Image 1

to be like this:

Image 2

[zewa666]

Hmm good question, i feel like whoever has an Extension installed in VSCode would expect it to work. If we disable it, people might not know what happened. You can disable jshint in a workspace basis but even then im not sure If we should second guess the users preference.

[adriatic]

I think that I have not explained it sufficiently, so let me try: based on the discussion in Switch to eslint issue combined with the fact that Rob ships navigation skeletons in the form that uses eslint (not jslint), we can safely assume that this is the implicit direction for all aurelia samples. If that is a valid deduction, we can either recommend the user to add the directive "jshint.enable": false to his user settings in vscode, or to add this same instruction to the settings that the aurelia-vscode-extension does that instead.

My suggestion is based on my belief that there is a large group of Aurelia users that consider vscode as their tool of choice.

[zewa666]

I think I got that, but there are more linters out there with VSCode Support, so should we now disable all of them?

[adriatic]

I believe that the most polite way to treat this to write a paragraph in the README.md for your samples that explain this situation and offer the solution depicted above (Image 1 and Image 2).

In order for this to work, we need to be sure that these aurelia-store sample applications are built the same way as the Aurelia Skeleton applications (see https://github.com/aurelia/skeleton-navigation/pull/178), because disabling jshint ("jshint.enable": false) will leave the app set to use eslint (and maybe some other linter, which could be another problem). The decision "we need to be sure that these aurelia-store sample applications are built the same way as the Aurelia Skeleton applications" needs to be made at the core team level of course.

Until @zewa666 mentioned that there are more than two linters, I thought that having @eriklieben's vscode extenstion disable jshint, but that is clearly bad approach, because it assumes that all folks using vscode have installed Aurelia vscode extension and that the application being developed as complied with the https://github.com/aurelia/skeleton-navigation/pull/178 rule.

All this writing, because I got really "scared" seeing how much vscode complains about the perfectly innocent aurelia-store sample application.

[zewa666]

To be fair i think the Readme for an example app shouldnt really be talking about some general js ecosystem related topics. Jshint for one already lost against eslint in popularity and secondly it isnt of any specific importance for the examples repo. Skeletons would be perhaps another Story since one could expect devs to use them as a basis for new projects.

[adriatic]

I agree completely - and mentioned this problem report only because jshint / eslint issue appeared here. My point is that as the author of these samples you need to ensure that they all compile and run as delivered (something that did not happen in my own encounter with them)

Far from me to feel the need to tell you how to wrap your gifts (to the community) - I am rather still in the spirit of worrying about any / all Aurelia samples and related guides that made me start the AUCS thing