-
Notifications
You must be signed in to change notification settings - Fork 38
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
fix: lint does not work on new Otter webapp #1671
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit a0dfc77. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
packages/@o3r/eslint-config-otter/schematics/ng-add/linter/index.ts
Outdated
Show resolved
Hide resolved
...ges/@o3r/eslint-config-otter/schematics/ng-add/linter/templates/__dot__eslintignore.template
Outdated
Show resolved
Hide resolved
packages/@o3r/eslint-config-otter/schematics/ng-add/linter/templates/tsconfig.eslint.json
Outdated
Show resolved
Hide resolved
25314d1
to
453ecc6
Compare
packages/@o3r/eslint-config-otter/schematics/ng-add/linter/templates/tsconfig.eslint.json
Outdated
Show resolved
Hide resolved
453ecc6
to
ad2c786
Compare
83037f9
to
0bfa244
Compare
0bfa244
to
9bb4f34
Compare
db1e4fc
to
bc49997
Compare
|
||
expect(() => packageManagerInstall(execAppOptions)).not.toThrow(); | ||
expect(() => packageManagerRunOnProject(projectName, isInWorkspace, {script: 'build'}, execAppOptions)).not.toThrow(); | ||
expect(() => packageManagerExec({script: 'ng', args: ['lint', projectName]}, execAppOptions)).toThrow('Lint errors found in the listed files'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we actually expect it to throw ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this point, yes. The goal is to be able to run the linter.
In a future PR I plan to
- fix all linter errors that are not fixable with
lint --fix
- run the
applyLintFix
after app and lib generation and - write IT tests to make sure there are no lint errors for apps and libs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit strange actually, that means that a default application is failing the linter, maybe it is true for the moment but I don't think it should be a condition of the IT.
If we align the generated app with the linter rules it will fail your test each it is incorrect.
I understand that your plan is to be able to run the --fix
and testing that the app is passing the linter after its run but it does not really justify to have this test today :S
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose was to make sure the linter is running. I have adapted the condition to test that the previous error is no longer thrown.
|
||
expect(() => packageManagerInstall(execAppOptions)).not.toThrow(); | ||
expect(() => packageManagerRunOnProject(projectName, isInWorkspace, {script: 'build'}, execAppOptions)).not.toThrow(); | ||
expect(() => packageManagerExec({script: 'ng', args: ['lint', projectName]}, execAppOptions)).toThrow('Lint errors found in the listed files'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit strange actually, that means that a default application is failing the linter, maybe it is true for the moment but I don't think it should be a condition of the IT.
If we align the generated app with the linter rules it will fail your test each it is incorrect.
I understand that your plan is to be able to run the --fix
and testing that the app is passing the linter after its run but it does not really justify to have this test today :S
76a0389
to
dcf32fd
Compare
if (eslintFile.extends.indexOf(tsEslintParserDep) === -1) { | ||
eslintFile.extends.push(tsEslintParserDep); | ||
const eslintConfigOtter = '@o3r/eslint-config-otter'; | ||
if (eslintFile.extends.indexOf(eslintConfigOtter) === -1) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if it extends a config that extends '@o3r/eslint-config-otter'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is a corner case that isn't currently covered
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dcf32fd
to
ffe96dd
Compare
ffe96dd
to
f32b080
Compare
f32b080
to
a0dfc77
Compare
Proposed change
Related issues