Re-style the javascript for gulpfile

[AemieJ]

• As discussed in PR#3879, the basic syntax and styling were overlooked for the gulpfile.js. I have replaced the usage of == with === and != with !== to create a strict comparison.
• Apart from that, I observed that there were statements that included semicolons and a few that didn't hence to bring consistency, I included semicolons for each statement.

[djencks]

Thanks for looking into this, this is definitely an improvement.

I'm used to and prefer no semicolon line ends.

I'm used to projects enforcing style with ESLint and an .eslintrc file, and providing lint and lint-fix scripts in package.json.

The .eslintrc files I use are

{
  "extends": "standard",
  "rules": {
    "arrow-parens": ["error", "always"],
    "comma-dangle": ["error", {
      "arrays": "always-multiline",
      "objects": "always-multiline",
      "imports": "always-multiline",
      "exports": "always-multiline"
    }],
    "max-len": ["error", {
      "code": 120,
      "ignoreStrings": true,
      "ignoreUrls": true,
      "ignoreTemplateLiterals": true
    }],
    "spaced-comment": "off"
  }
}

and the bits of package.json

  "scripts": {
    "lint": "eslint lib/**/**.js test/**/**.js",
    "lint-fix": "eslint lib/**/**.js test/**/**.js --fix"
  },
  "devDependencies": {
    "eslint": "~6.7",
    "eslint-config-standard": "~14.1",
    "eslint-plugin-import": "~2.19",
    "eslint-plugin-node": "~10.0",
    "eslint-plugin-promise": "~4.2",
    "eslint-plugin-standard": "~4.0",
    "prettier-eslint-cli": "~5.0"
  }

I'm not sure if all the dependencies are needed.

What do you think about adding these scripts?

[AemieJ]

@djencks I was planning to add the similar formatting eslint and prettier styling as that in camel-website. I think the code you showed is similar to that.

[djencks]

Great! Mine is derived from Antora so is very similar.

[djencks]

I think it would be better to have this in the .eslintrc file:

/eslint semi: ["error", "never"]/

Can we remove the unused import here instead of suppressing the warning?

/* eslint-disable-next-line no-unused-vars */

Unfortunately there's a merge conflict now, can you rebase on master? I think it might be clearer (if you can figure out how :-) to have the added lint-config files in one commit and the effect of running lint in a separate commit. I've found this useful for splitting commits: https://hisham.hm/2019/02/12/splitting-a-git-commit-into-one-commit-per-file/

[djencks]

Also, I prefer separate lint and lint-fix scripts. If lint changes the source, you have to run git status to find out if anything changed, and lint can't be run to fail the build if there are lint errors.

[AemieJ]

@djencks I thought to remove it but I wanted to check if there was any importance to include it in the first place. That's why I suppressed the warning for the meanwhile.

[zregvart]

Seems that we have one set of files missing here.