-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add checks for general module template adherence #6
Comments
Suggestions:
|
A question was raised in standup this morning about the overlap between the rule being discussed in this ticket and the existing rules we've completed and have planned. If there are already certain files we are checking via other rules, it seems that this rule would also check those files, so should we exclude them from this rule? We could do this, but we would have to make two assumptions:
The first assumption is valid; the existing rules do not make a containment check, but we can easily fix that. The second assumption, however, creates a problem. One of the guiding principles behind the existing rules is that they should be as bite-size and have as few responsibilities as possible. This way, a project can disable and enable individual rules to suit its needs. However, in taking this fine-tuned approach we cannot guarantee that all of the files and configuration in the module template are being covered by a rule. In other words, if a change is made to the module template in the future, it is possible there may not be a rule in |
I am going to suggest, based on the size of this ticket, that we hold off until we get through all of the other ones first. If the main goal of this ticket is to address potential gaps in existing rules, perhaps there is a way we can compare the rules we have with the module template and verify that everything is covered. Or perhaps having gaps is just an inevitability based on the way this tool is designed. I'll have to give this a bit more thought. |
Although we have checks for specific tools — ESLint, TypeScript, etc. — it may be that we make a change to the module template and don't have a specific rule around it in
module-lint
. Therefore, we need a set of rules to act as catch-alls. Although these rules may not be perfect — the output of these rules may not be useful as the output of more specific rules and may not account for all of the intentional divergences from the module template — it's better than nothing.Given this, for a given project, we want to ensure that:
.js
,.cjs
,.mjs
, and.ts
files in the module template exist in the project, and the project's version of that file, when run, is a superset of the module template's version.js
and.cjs
files that containmodule.exports =
or.mjs
and.ts
files that containexport
, and we want to run the whole file within both the module template and project to obtain an object (as in, create a small Node script which imports the file and outputs the resulting object as JSON, write the JSON data to another file, and then compare JSON). If the file produces an error when run, then bail and skip to the next strategyrm -rf
or something, but perhaps that is not possible..gitignore
,.gitattributes
, etc. It would also account for.js
,.cjs
,.mts
, and.ts
files that aren't configuration files for some reason.README.md
andCHANGELOG.md
since these are highly customized for each project.README.md
is checked in Add README-related checks #53, andCHANGELOG.md
is checked in Add changelog-related checks #48. Also skip files insrc/
since they're meant to be examples..github/pull_request_template.md
before comparing, since it's only for the module template.The text was updated successfully, but these errors were encountered: