Establish a common code style about nodejs-itoolkit

[kadler]

@markdirish Yes, we can't break compatibility, but we can disable linting for those lines: https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments

Ideally, we'd also come up with an API which is conformant and make the old APIs deprecated, but that should be a separate issue.

[markdirish]

We should probably get a standard one across all projects. Is the one in idb-pconnector good? There are some really famous JavaScript style guides we might follow, like the AirBNB JavaScript style guide. Might be easier to use a tried and tested one like that.

This is a great idea though.

[abmusse]

We should probably get a standard one across all projects

I totally agree

I enjoyed using that eslint file for idb-pconnector project.

I'm open to looking into other style guides,

It really comes to preference when choosing from the popular style guides,

For example:

some enforce semicolons after each line while others do not.

Of course we can use their style guide as a base and tweak it to our liking.

[kadler]

If we're going to switch things up and enforce a style, there's going to be a lot of changes, which will make history harder to follow (git blame, etc). Usually when this is done, you do it in one big change that's a clear divider line between old and new, so this should be top priority.

I'd also echo @markdirish's suggestion to use a common community style. I would not customize it, but stick to the style since that would mean less friction for outside developers to contribute.

[markdirish]

It seems my initial sense that the airbnb style as a sort of 'gold standard' seems to be correct. I followed the instructions on this website to install eslint and airbnb style as devDependencies (which we should eventually do for all our repos). I am currently running the linter instructions from eslints website under Local Installation and Usage: Eslint Getting Started.

There are a few configurations in the style that are weird to me (100 max line length instead of 80), but I think I agree with @kadler that we shouldn't change it, and should instead adapt the way we code. That will help keep the code standardized.

I am going to lint this repo and push to a new v1.0 branch, since that is the milestone we are shooting for. We can then work on some of the other improvements/enhancements on that branch and get this repo ready for 1.0

[markdirish]

One issue that I've run into is the 'new-cap' rule, which says that constructors (and by extension classes) need to begin with a capital letter. Obviously this becomes an issue for our tendency to preface our class names with i, as in iPgm. If we are going to adopt this, we are going to have to change to IPgm, which I don't have a problem with, but I want to feel out how everyone feels.

[abmusse]

Also noticed that this guide disallows for of which I do not totally agree with.

Some use cases where I would want for of when iterating over a list then using await on a method that returns a promise.

The guide recommends using for each method which does not play nice with async and await.
see this

I could using the good old for(let i = 0; i < list.length; i++) but the for of statement is much cleaner imo.

[abmusse]

Closing this since we established common code style with AirBNB JavaScript style guide.