Fix: Lint all JS/CSS files with Standard/Stylelint

[mao-sz]

Because

The current lint script runs only in app/javascript which therefore misses the JS config files in the repo root. Can't see a reason for these to not be linted either.

The current stylelint script also misses application.tailwind.css.

This PR

• Amends paths for lint and stylelint scripts
  • Removes --verbose flag for standard as it isn't a valid flag.
• Amends stylelint config with Tailwind at-rules and import-notation (for consistency within file)
• Fixes JS and CSS lint errors in missed files.

Issue

Closes #XXXXX

Additional Information

Opening up the standard path revealed JS controllers in

• https://github.com/TheOdinProject/theodinproject/blob/main/app/components/project_submissions/item_controller.js
• https://github.com/TheOdinProject/theodinproject/blob/main/app/components/overlays/dialog_controller.js

Is this intentional? I thought they would go in app/javascript/controllers.

Pull Request Requirements

• I have thoroughly read and understand The Odin Project Contributing Guide
• The title of this PR follows the keyword: brief description of change format, using one of the following keywords:
  • Feature - adds new or amends existing user-facing behavior
  • Chore - changes that have no user-facing value, refactors, dependency bumps, etc
  • Fix - bug fixes
• The Because section summarizes the reason for this PR
• The This PR section has a bullet point list describing the changes in this PR
• I have verified all tests and linters pass after making these changes.
• If this PR addresses an open issue, it is linked in the Issue section
• If applicable, this PR includes new or updated automated tests

[KevinMulhern]

Great stuff! thanks @mao-sz

[mao-sz]

Cheers @KevinMulhern
Thoughts on the 2 JS controllers bit in the additional info part of the PR form? If action is required then I can PR separately

[KevinMulhern]

Sorry I missed that @mao-sz. Yep, those are intentional.

Ideally we’d only have generic controllers that can be used anywhere in the app, living in app/javascript/controllers. In practice though, that’s easier said than done, and I think we have a few controllers there with fairly narrow use cases.

View components make it easier though. They allow Stimulus controllers to live in a component’s sidecar when the behavior is tightly coupled to that component. It's mostly a DX win - everything related to the component lives in one place, so there’s less context switching - but it also clearly communicates that the controller is not meant to be reused elsewhere.

[mao-sz]

Gotcha 👍