Using ESLint with Visual Studio Code

[thrinn]

If you start using the ESLint extension to check your code, the first thing to do is creating a .elintrc.json file. This file contains some important configuration settings, and without this file ESLint will not work. An easy way to create the file is using the command palette:

• Open the command palette using Ctrl-Shift-P
• Start typing "create" -> You should already see an "ESLint: Create .eslintrc.json File" command you can execute

I put this file in my webroot\user folder. It will be used for all apps stored in any sub folder. So far, so good.

What I wanted to achieve:

• I want to get a warning if I mistype a variable (like Imatch instead of IMatch).
• I don't want to get a warning if I use IMatch (or IMWS, or...) correctly!

I like to structure my code by putting all JavaScript functions in a separate module. Instead of putting all JS between <script> tags in the index.html file I put them in a separate app.js file which will be included in the head section like the IMatch helper libraries:

Code Select Expand


    <!-- The IMatch and IMWS helper libraries - they make access to IMWS and IMatch very easy -->
    <script src="/system/imws/imwslib.js"></script>
    <script src="/system/imatch/imatchlib.js"></script>

    <!-- Own JavaScript functions -->
    <script src="app.js"></script>


Unfortunately, I got a lot of ESLint warnings in my app.js file:

Code Select Expand


'$' is not defined. (no-undef)
'IMWS' is not defined. (no-undef)
'IMatch' is not defined. (no-undef)

To get rid of the first warning, I had to add an option to the .eslintrc.json file: You will find an "env" section defining the environments you are using in your code. Just add "jquery", and the warning about an unknows $ variable disappears. My "env" section looks as follows:

Code Select Expand


"env": {
        "browser": true,
        "commonjs": true,
        "es6": true,
        "node": true,
        "jquery": true
    }


Secondly, I wanted to make ESLint aware of IMWS and IMatch as "known global variables". Also not difficult: Just add a "globals" section to the .eslintrc.json file and define both variables:

Code Select Expand


    "globals": {
        "IMatch": false,
        "IMWS": false
    }

Setting both to "false" means that they are used only as "read-only" variables, if I interpret the ESLint documentation correctly. I have no intention to modify IMatch or IMWS, so I feel this is the correct setting.

After these modifications ESLint behaves like I want it to behave.

There are surely other ways to configure ESLint (I am not an expert with this tool!) but at the moment it works for me.
Just to share some pitfalls I fell into and how to avoid them...

[ubacher]

Thanks for this. Will soon need to follow these instructions.

I am currently thinking about what "defensive programming" methods I can use as I tackle this programming environment.
ESlint is (will be) a component of this.

This programming (once understood) is very powerful but it also allows you to "shoot yourself in the foot."
Dynamic variables, dynamic arrays and dynamic functions are all a software engineer's nightmare (and a hacker's delight.)

[Mario]

ESLint is very powerful and can be configured in many ways. The web site explains a lot, and you can find additional help and suggestions in the usual programmer communities (e.g., StackExchange). Google's your friend here.

I use the following ESLint for the IMatch webtoot:

Code Select Expand


{
    "env": {
        "browser": true,
        "commonjs": true,
        "es6": true,
        "node": true,
        "jquery": true,
        "jasmine":true
    },
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "sourceType": "module"
    },
    "rules": {
        "no-const-assign": "warn",
        "no-this-before-super": "warn",
        "no-undef": "warn",
        "no-unreachable": "warn",
        "no-unused-vars": "off",
        "constructor-super": "warn",
        "valid-typeof": "warn"
    },
    "globals": {
        "IMWS": false,
        "IMatch": false,
        "IMatchTranslate": false,
        "ol":false
    }
}


ol is for OpenLayers (Map Panel).

[sinus]

When I read this and other threads about creating scripts, then it let me back without a lot of hope.
This whole stuff to create a script seems to be very difficult.

When I remember back at Visual Basic then it it for sure not so powerful than JS, but it looks for me much easier.

If here some experienced people have difficulties to write a script, how can I do once a script?
I have to try in the next future some examples (where I will start with Mario's examples), but I have now really not a lot of hope, that I will get it.

Makes me a bit depressive. 

[thrinn]

Makes me a bit depressive. 

I sincerely hope not! 

A lot of this is just to get you up and running. And ESLint is purely optional (but helpful)!
At BASIC times, you had the IDE and that was it. No need to think about extensions because there weren't any. Now you have the choice between different editors, a ton of extensions and whatnot.

I think the biggest hurdle at the moment is the asynchronous paradigma. Admittedly, to understand this Promise-based stuff gives me a still bit of a headache. But once understood, writing Apps should not be more difficult than BASIC.

Also, nicht die Ohren hängen lassen!

[sinus]

Makes me a bit depressive. 

I sincerely hope not! 

A lot of this is just to get you up and running. And ESLint is purely optional (but helpful)!
At BASIC times, you had the IDE and that was it. No need to think about extensions because there weren't any. Now you have the choice between different editors, a ton of extensions and whatnot.

I think the biggest hurdle at the moment is the asynchronous paradigma. Admittedly, to understand this Promise-based stuff gives me a still bit of a headache. But once understood, writing Apps should not be more difficult than BASIC.

Also, nicht die Ohren hängen lassen!

Also, Du bist ja sehr nett, Thorsten, DANKE! 

Maybe you are right, it sound only a bit difficult, but at the end it is maybe not that difficult.
If you find a good source with an EASY explanation about this asynchron - stuff, please let it me know.

OK, you made my day a bit better again, thanks.  (manchmal ist man eh nicht so gut drauf und dann gibt einem so ein oder mehrere threads gerade noch den Rest  )

[Mario]

@Sinus:

ESLint is just an optional utility. It has been written by programmers to help JavaScript programmers (including newbies) to write better code, to see syntax errors like missing ) or } immediately highlighted in the source code etc.

Visual Studio Code (like all good programmer editors) installs simple and works right out of the box for most users. But the real power lies in the many free extensions you can use. There is a spell checker, for example. There is ESLint for syntax checking. And there are thousands of other extensions for other things.

You don't need to use those but they are helpful. Like, having a spell checker when you write documentation in Visual Studio Code. Which I did, just check out https://www.photools.com/dev-center/doc/imatch/ - this documentation was written by me in Visual Studio Code.

@thrinn

Promises are easy:

IMWS.get('v1/info').then(function(response) {
    // Do stuff
},error(status) {
    // Do stuff when it fails
}.always() {
    // Do stuff in any case
});

Always the same. With every IMatch. IMWS. or other AJAX calls you make.
There are a lot of additional features available for promises in jQuery (see docs), but for most IMatch apps all you need is the .then() logic.

When you find yourself in a situation where you need to wait for multiple promises to finish (several parallel calls pending) you can use jQuery's when() function to wait for all of them and the continue in your script.

I agree that this requires some rethinking of old linear programming concepts. But this is the only way to keep apps responsive. If your app runs inside IMatch, calling an endpoint usually takes almost no time. But if your app uses a remote IMWS server, the endpoint may need several seconds to return a response. Even IMatch endpoints may take several seconds to complete, if IMatch is busy otherwise or you run queries against large databases.

This is the reason why AJAX (the technology that drives all the .get() and .post() mumbo-jumbo) has been designed to been asynchronous from ground up.

When you make a get() request, think:

"OK, this takes 10 seconds to complete, and then it calls then() and does this..."

This may be helpful in structuring your script.

[sinus]

Thanks, Mario, too!

The day will come, when I dive into it to lern more. 

[Mario]

A day without learning something new is a day lost. 

[sinus]

A day without learning something new is a day lost. 

Hm, yep, but I have to earn some money like you  but I do not earn money with scripting or programming, but with taking pictures. 

[Mario]

So, automation in your DAM workflow is good. You can do more in less time, let the machine work.

Last December I've spent many days learning how to automate the 90 steps required to build, installer creation, test and ship IMatch Anywhere. Before, it took me several hours do do it all manually. And there were many places where errors could creep in. Now (without the test cycle) the entire process takes about 10 minutes.

I applied this know-how also to IMatch 2017. Cutting down the mostly manual work build process from about 2.5 hours to 10 minutes. And I could add many tests which would have been to boring or slow to do by hand.

Now that we have this fantastic app platform in both IMatch and IMatch Anywhere I can use that to implement features which save my users time. Which improve the data quality without extra work. Create ways to incorporate cloud-based intelligence, e.g. for image analysis, face recognition etc. For users who want this, not enforced of course.

Apps that help you with writing keywords and captions. Apps which can identify runner numbers (sport photographers), license plates or brands in images and then store that in the metadata. Apps which "understand" what an image is showing and can fill in all related data. Sentiment analysis for the persons in the image, age classification, face recognition. Apps that can find all images with an orange or a milk bottle :-)

Reduce the time the user has to spend with adding and checking metadata.

I have also ideas for apps that visualize things better. Real family trees for genealogy purposes. Better ways to pick data from the thesaurus. A light table view where you can move around images and stack them like you would do on a real light table. Visualization of file relations to quickly show you how files relate.

The apps technology I have now makes all this possible, while greatly reducing the time to develop these things. And, since it runs in a browser. it will work with IMatch locally and IMWS remotely.

[sinus]

VERY interesting, Mario!

Thanks for your détailed answer.