fluid-project / fluid-lint-all

Consolidated linting logic free from any particular build technology
BSD 3-Clause "New" or "Revised" License
0 stars 5 forks source link

GH-38: Add `package-lock.json` to excludes for additional checks (resolves #38). #41

Closed the-t-in-rtf closed 3 years ago

the-t-in-rtf commented 3 years ago

See #39 for details.

@greatislander, I have cut 1.1.4-dev.20210604T105954Z.979a7d8.GH-38 with the changes proposed here. Please give it a try, hopefully it'll work better for you.

greatislander commented 3 years ago

Hi @the-t-in-rtf — this works for the package-lock.json file. Now I'm getting an error from the same check for the package.json file. I created it using npm init and added fluid-lint-all via the NPM CLI so it doesn't match our expected indentations. Do you think it's worth excluding this by default as well? I'm not sure if it's beneficial to be linting the package.json file if it's not being edited by hand otherwise whenever one uses the NPM CLI to add a dependency it will reformat it and necessitate manual re-indentation. But that may be just my preference so I'm fine to manually excluded it in my projects.

the-t-in-rtf commented 3 years ago

I would rather leave package.json in by default. I vaguely remember us explicitly adding checks for package.json because of indentation and other style issues in other projects. Although I do issue commands as well, I often use my IDE's package version checking and auto-completion, and certainly write script blocks and other stuff in a text editor, so for me it's an easy sell.

From working with the check for a while, I can say that once you take the time to indent the file (for example letting ESLint "fix" it), npm will follow your style from that point on. So, it's a one time switch away from npm's defaults and you shouldn't have issues with content added/updated by npm install and other commands.

the-t-in-rtf commented 3 years ago

Or of course you can opt out of checking that file altogether in your fluidlintallrc.