Skip to content
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

Improve experience when using ruleset in repo with mixed JS, TS, and Angular code #79

Open
jattasNI opened this issue Jan 7, 2022 · 1 comment
Labels
documentation Improvements or additions to documentation needs-proposal Needs investigation and a proposal to implement

Comments

@jattasNI
Copy link
Collaborator

jattasNI commented Jan 7, 2022

In this Skyline PR I enabled linting for the JS files in an Angular project. This situation is common because of config files like karma.conf.js and .eslintrc.js. I hit a couple small bumps that would be nice to address in this repo.

  1. Had to manually modify the repo's .eslintrc.js to use the JavaScript ruleset for files matching *.js. We should either document this as our recommended approach or change our Angular and TS rulesets to apply to JS files too.
  2. I had to modify angular.json lintFilePatterns to include *.js since the npm run lint command called ng lint. We should document this.
  3. A few rules failed on the default karma.conf.js generated by Angular. I chose to suppress those rules. In another case we chose to fix them (see discussion in linked PR). It would be nice to settle on a preferred approach and include guidance in our repo since most projects will likely hit the same errors.
    • if we choose to suppress, we could change our ruleset to do this automatically for karma.conf.js
    • if we choose to fix, we could add notes on each rule's docs or create StackOverflow posts explaining how to fix
@jattasNI
Copy link
Collaborator Author

General agreement at our meeting today that we can solve most of this with documentation. For issue 3 above, adding an override for karma*.js which turns off a couple rules seems preferable, but we'd be fine with docs if we run into issues with that approach.

@mure mure added the documentation Improvements or additions to documentation label Jun 30, 2022
@rajsite rajsite added the needs-proposal Needs investigation and a proposal to implement label Apr 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation needs-proposal Needs investigation and a proposal to implement
Projects
None yet
Development

No branches or pull requests

3 participants