Docs: Give example for adding meta.name and meta.version to plugin config

[MikeMcC399]

Docs page(s)

Create Plugins > Meta Data in Plugins

What documentation issue do you want to solve?

The text says:

The meta.name property should match the npm package name for your plugin and the meta.version property should match the npm package version for your plugin. The easiest way to accomplish this is by reading this information from your package.json.

If plugins are released using semantic-release, where the version is not updated in the repository, and is only changed in the npm registry, it may not be obvious how to achieve the synchronization of version data between the plugin's meta.version property and the published package.json's version property.

Also, providing an example of how to automate this step would help towards the name and version data being consistently published across all plugins, whether or not the committed package.json contains an up-to-date version property.

What do you think is the correct solution?

In https://github.com/eslint-community/eslint-plugin-eslint-comments/blob/main/configs.js there is an example which uses:

const { name, version } = require("./package.json")

const plugin = {
    meta: { name, version }
}

Possibly this could be added to the example in Create Plugins > Meta Data in Plugins and published (or the equivalent code using import instead of require).

Participation

• I am willing to submit a pull request for this change.

Additional comments

I looked through the plugins which have been marked as v9 compatible on #18391 and most of them actually store their version in the committed package.json. Examples of ones which do not are:

• https://github.com/eslint-community/eslint-plugin-eslint-comments
• https://github.com/eslint-functional/eslint-plugin-functional
• https://github.com/playwright-community/eslint-plugin-playwright

[nzakas]

That sounds like a good idea. Can you submit a PR for that?

[MikeMcC399]

@nzakas

That sounds like a good idea. Can you submit a PR for that?

I'm glad you agree that this would be a good idea!

When I came to writing something I realized that for ESLint v9 there are no recommendations about how to generate a plugin automatically or where to place a JavaScript config file. (PR eslint/generator-eslint#179 is still open.) For ESLint v8, Yeoman is recommended and this generates a lib/index.js file, i.e. in a sub-directory of the plugin's root directory.

Would you want to make some sort of best practice recommendation / default location for a config file? If there is none, then I would have to say that the import / require example assumes that the config file is in a certain location relative to the package.json file.

[MikeMcC399]

Unfortunately I now realize that I only have a solution for CommonJS, not for ESM, so I would need to leave proposing a code example to somebody with more JavaScript Node.js skills than I currently posses.

Importing from JSON modules is experimental and has other restrictions.

[nzakas]

You can actually use the same solution in both CommonJS and ESM: just read in package.json using fs and then run it through JSON.parse() to get the values.

[nzakas]

@MikeMcC399 are you going to send a PR for this?

[MikeMcC399]

@nzakas

are you going to send a PR for this?

If I had the skills to convert what you suggested into code then I would, but I don't. So regrettably, no I can't contribute a PR to implement this suggestion.

The box has to remain unticked:

• I am willing to submit a pull request for this change.