Announcement of Discord chat server

[brettz9]

Just an announcement...

I've also filed jsdoc/jsdoc#1808 to invite jsdoc proper to get involved and possibly take ownership. (I thought a chat server for eslint-plugin-jsdoc, while possible, would be better under a more broad jsdoc umbrella. Note there is an #eslint-plugin-jsdoc-specific chat room, though perhaps we can split that further as needed into help and development rooms).

As mentioned there, no promises at all on necessarily even replying to questions or comments there, but thought there should be a space.

You can join by visiting https://discord.gg/kFFy3nc

And if I didn't formally announce it here before, there is also a jsdoc awesome list I started at https://github.com/brettz9/awesome-jsdoc .

[neverendingqs]

Thoughts on using the new GitHub discussions tool? It seems to meet this need, has searchable threads, and doesn't require leaving GitHub.

[brettz9]

Thoughts on using the new GitHub discussions tool? It seems to meet this need, has searchable threads, and doesn't require leaving GitHub.

@neverendingqs : I sympathize with the concern, but I'm inclined to keep using the Discord server as the chat nature suggests and facilitates the more temporal and tentative nature of the assistance offered. I don't want to tacitly suggest that by our accepting them, all discussions will necessarily get a response or have action taken. Anything of importance should be filed as an issue.

[coffee-coder99]

@brettz9 Unfortunately, I can't join discord at work, and there is no discussion forum outside of discord. Hopefully, this place is okay.

I wonder if it would be possible to lint an issue that tsserver reports. Overall, my goal is to remove the need for the tsc/tsserver steps in compilation or checks. Which means I need the eslint rules to catch something like this as an error.

/** @type {string} **/
let x = 7;

My current eslint.config.js

// @ts-check
//
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
    eslint.configs.recommended,
    ...tseslint.configs.recommended,
);

and my .eslintrc.json

{
  "env": {
    "browser": true,
    "es2021": true
  },
  "plugins": ["jsdoc"],
  "extends": ["plugin:jsdoc/recommended", "eslint:recommended"],
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "rules": {
    "jsdoc/check-types": 1,
    "indent": ["error", 4],
    "linebreak-style": ["error", "unix"],
    "quotes": ["error", "single"],
    "semi": ["error", "always"]
  }
}

Using the latest of jsdoc and this plugin, and eslint. All configured today.

[brettz9]

@coffee-coder99 : Take a look at jsdoc/no-restricted-syntax and the examples. You will want a comment selector like JsdocBlock:has(JsdocTag[tag=type].

[coffee-coder99]

@brettz9 thank you for helping. It appears no 'type-checks' are done. Is there something I could be missing?

/**
 * @returns {string}
 */
function yesterday() {
    const date = new Date();
    date.setDate(date.getDate() - 1);
    return formatDate(date);
}

This is only showing a warning for missing returns description. I have reconfigured everything to use .eslintrc.cjs

/* eslint-env node */
module.exports = {
  extends: ['eslint:recommended', 'plugin:@typescript-eslint/recommended', 'plugin:jsdoc/recommended'],
  env: { browser: true, node: true },
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint', 'jsdoc'],
  rules: {
    'jsdoc/no-restricted-syntax': ['error', { contexts: ['JsdocBlock:has(JsdocTag[tag=type])'] }]
  },
  root: true
};

The original case, still shows no type issues either.

/** @type {string} **/
let x = 7;
console.log(x);

[coffee-coder99]

I guess what I'm asking is if tsc/tsserver MUST be utilized in conjunction, or if there is a way to run this type of analysis with only eslint.

[brettz9]

Re: the rule, please try this instead:

'jsdoc/no-restricted-syntax': ['error', { contexts: [
  {
    context: 'any',
    comment: 'JsdocBlock:has(JsdocTag[tag=type])'
  }
] }]

I am not personally familiar with tools which run tsc through eslint. It looks like https://www.npmjs.com/package/eslint-plugin-tsc might do this, but I haven't tried it. Most projects use both since tsc does its own checking independent from normal ESLint rules, and the prominent TypeScript plugins which exist try to enhance rather than replace tsc. Their output is at least visible together in tools like Visual Studio Code though.