Remove dot in generic types

[joeyparrish]

Google Style for JavaScript no longer favors a dot in generic types. For example, where we currently have Array.<string>, the latest style guide says we should now use Array<string>.

[nbcl]

I have recently read the styleguide and if I understand correctly, I assume this change should apply to every type.

If the previous assumption is correct, then the fix can be achieved using regular expressions globally.

If that outcome is what this issue is trying to achieve, I would assume the best course of action would be running a regex find-and-replace by a trusted maintainer instead of reviewing an extremely big pull request from an outside contributor, so here is what I used in my approach:

// fix general
'find': ([a-zA-Z]+)\.<([a-zA-Z]+)
'replace': $1<$2

// fix nonNull
'find': ([a-zA-Z]+)\.<!([a-zA-Z]+)
'replace': $1<!$2

// fix mayBeNull
'find': ([a-zA-Z]+)\.<\?([a-zA-Z]+)
'replace': $1<?$2

Please note that each, the "general" and "nonNull" find-and-replaces, have to be run twice due to some files containing multiple instances in the same line.

I have tested this in my personal fork @nbcl/shaka-player:feat-2643 to a resulting 1,226 additions and 1,226 deletions in 198 files, without creating any issues in build/all.py.

I really hope this can be of use @joeyparrish!

[joeyparrish]

Yes, I think a mass search-and-replace is in order. But ideally, we would also convince eslint to enforce the new style at the same time. Without enforcement, we will definitely slip into old habits.

[joeyparrish]

@nbcl, if you can figure out if eslint has a rule for this, and enable it, we would love to receive a PR with the changes. Thanks!

[nbcl]

Unfortunately, I was not able to find an official ESLint rule for this change, but I have several insights that I think could be of help to point towards the right direction.

Initially, I discovered that none of the different options in the valid-jsdoc rule could be used to achieve the result that we are looking for in this issue. This limitation could mainly be due to the end-of-life built-in support of JSDoc in ESLint v5.10.0.

They do, however, recommend an alternative.

If you would like to continue checking JSDoc comments using ESLint, we suggest using the community-supported eslint-plugin-jsdoc plugin.

I have tested it in my personal fork, @nbcl/shaka-player:feat-2643-eslint under multiple settings, but the following seem to be the ideal.

'settings': {
    'jsdoc': {
      'preferredTypes': {
        '.<>': '<>',
      },
      'mode': 'closure',
    },
  },

The plugin managed to correctly detect 1245 problems, which appear to be the total amount of incorrect instances.

This is more that the 1226 detected in my previous comment, as I now learned my proposed regular expressions where not able to find instances of the following structure:

• .<{
• .<*>
• .<?>
• .<\n

I find this new plugin to be a good approach, however, it has the following downsides.

• A new devDependency should be added (eslint-plugin-jsdoc).
• Under my implementation, --fix was unable to resolve problems in some instances of @private, @property, @typedef, @param, @type and @return, so some manual fixing was needed.
• Regular comments containing the pattern are not identified.

Although I was not able to come up with the solution, at least we now appear to know the total amount of incorrect instances and a plugin that seems to achieve something similar to the needed outcome.

I really hope this information can be of help to find an ideal solution to this issue!