Create eslint-plugin-nodejs-internal repo

[nschonni]

Splitting off from previous discussion in #55

This would be a repo to be published as a NPM package that could be used for node core and repos want to follow those rules already set there. Suggesting eslint-plugin-nodejs-internal since there is already a eslint-plugin-node used, so it would be less likely to be confused

• copy over rules from https://github.com/nodejs/node/tree/master/tools/eslint-rules
• setup NPM publishing
• setup regression testing against nodejs/node like the remark-lint CI

[nschonni]

//cc @nodejs/linting

[mhdawson]

+1 from me

[ljharb]

Could it be named with "internal" or something, so people don't get confused and think it's for all node-based projects?

[nschonni]

@ljharb like eslint-config-nodejs-internal? I don't know what the restrictions are on word-breaks for config names

[ljharb]

There are no restrictions, and yes, that sounds great to me.

It could also go under a scope, if one is available, which would make it even less attractive for external consumption.

[nschonni]

OK, no issue for me, so I renamed the issue

[Trott]

My understanding of shareable configs vs. plugins is not great, so apologies for this, but since I'm guessing I'm not the only one who will be wondering:

Is the idea here that most repos that used this would install both the shareable config and the plugin? The plugin would be a peer dependency of the shareable config? Or would one make the other not necessary as it would be a superset?

[nschonni]

Sorry, the plugin https://www.npmjs.com/package/eslint-plugin-node isn't related to the rules in the core repo, but is used by a bunch of other common shareable configs. No relation to setting up a shareable config https://eslint.org/docs/developer-guide/shareable-configs

[ljharb]

A plugin can be a shareable config, but can also provide its own rules, like eslint-plugin-import.

A shareable config can only provide a config, like eslint-config-airbnb.

[nschonni]

OK, since there are some custom rules in core, should it be a plugin then?

[ljharb]

Yep, given that, it seems like a plugin is the right approach.

[Trott]

Oh, whoops, eslint-plugin-node isn't ours. I somehow got confused and was thinking about remark-preset-lint-node, which isn't ESLint or a plugin, but there you go. Never mind my question, although I guess I'm glad it surfaced the plugin vs. shared config question.

[ljharb]

eslint-plugin-node-internal seems like a reasonable choice - altho if node owns any usernames, a scoped package would be better.

[nschonni]

OK, updated title again 😄

[bnb]

+1, happy to help with setup if that's something that would be helpful.

[nschonni]

@bnb sure, if we have enough +1s now and you have the access that would be great!
If you want to seed it with the license and other files, we can start copying over content through PRs afterwards.
I think @nodejs/linting should probably be either admin or maintainer access on the repo

[targos]

Is there any repository that would like to follow the same rules as nodejs/node? I find most them very specific to core development and also related to the history of the project. I would personally never want to use the same rule set anywhere else ^^

[ljharb]

@targos the intention as i understood it was that it would only be used by projects seeking to be upstreamed into node core itself.

I very much agree that no other project would want to use node core's idiosyncratic eslint config :-)

[Trott]

I've created the repository at https://github.com/nodejs/eslint-plugin-nodejs-internal/ and given write access to @nodejs/linters, which includes @nschonni.

[Trott]

Re-opening because there's a checklist in this issue, and I guess we should get all those done before closing.

[nschonni]

I just copied those issues over to the repo to track there, so I'll close this one.
Repo still needs license and other boilerplate files too