Setup eslint plugin scaffold and basic CI actions

[haifeng-li-at-salesforce]

• Set up the scaffold for graphiql eslint plugin dev following the pattern from lwc-graph-analyzer and 'eslint-plugin-lwc`
• Introduce a simple Rule enforce-fool bar from ESlint.org to verify the coding/test workflow working
• Introduce lint, prettier and test actions

[sfdctaka]

@haifeng-li-at-salesforce There are conflicts in this branch that you need to resolve.

[khawkins]

I see both package-lock.json and yarn.lock. We should standardize on NPM or Yarn. I'd prefer NPM, as it doesn't require a separate install.

I've come to be of a mind to only use Yarn, pnpm, etc., if there's a specific set of features within those package managers that we're looking to adopt. Otherwise, vanilla NPM is the least effort to support.

[khawkins]

Also, with regards to using NPM: package-lock.json needs to be regenerated without nexus-proxy.repo.local.sfdc.net as the configured registry. Package lock entries should point to https://registry.npmjs.org.

[khawkins]

I think those are my main comments for the initial review!

[sfdctaka]

Can you check why prettier is failing on CI?

[sfdctaka]

LGTM!

[haifeng-li-at-salesforce]

Komachi plugin has the same pattern. Should we remove it too?

https://github.com/salesforce/eslint-plugin-lwc-graph-analyzer/blob/3abcba3c290a48f7067bebef39436f731487ac94/.eslintrc#L17

[ben-zhang-at-salesforce]

loving it :)

[haifeng-li-at-salesforce]

@khawkins
The below iscode snippet from komachi plugin:
https://github.com/salesforce/eslint-plugin-lwc-graph-analyzer/blob/3abcba3c290a48f7067bebef39436f731487ac94/.eslintrc#L21

[khawkins]

@khawkins The below iscode snippet from komachi plugin: https://github.com/salesforce/eslint-plugin-lwc-graph-analyzer/blob/3abcba3c290a48f7067bebef39436f731487ac94/.eslintrc#L21

Reading about all of that configuration more, I guess it doesn't matter too much: the .eslintrc configuration in this case is only going to apply to to any linting we do ourselves within the project. And then we override the parser configuration anyway, the only place we run the plugin within the project.

So I guess the configuration is meaningless in our case. 🙂 I don't feel strongly about if/when we update that in the eslint-plugin-lwc-graph-analyzer project. I'll add a small story for it.

[khawkins]

@khawkins The below iscode snippet from komachi plugin: https://github.com/salesforce/eslint-plugin-lwc-graph-analyzer/blob/3abcba3c290a48f7067bebef39436f731487ac94/.eslintrc#L21

Reading about all of that configuration more, I guess it doesn't matter too much: the .eslintrc configuration in this case is only going to apply to to any linting we do ourselves within the project. And then we override the parser configuration anyway, the only place we run the plugin within the project.

So I guess the configuration is meaningless in our case. 🙂 I don't feel strongly about if/when we update that in the eslint-plugin-lwc-graph-analyzer project. I'll add a small story for it.

I guess it technically applies to the linting we apply to our project—not the test code. Sorry, lots of moving parts! So if we had code within our plugin that used ES6 constructs—which we don't seem to—then we'd want those parsing options, because otherwise ESLint analysis of our codebase would throw errors.

Anyway, since we don't have that problem, let's just leave the configuration out. And if and when we choose to update our codebase to leverage ES6 or TypeScript or whatever, we can revisit.

[khawkins]

This is g2g for me. 👍