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

fix: lint does not work on new Otter webapp #1671

Merged
merged 1 commit into from
Apr 22, 2024
Merged

Conversation

vscaiceanu-1a
Copy link
Member

@vscaiceanu-1a vscaiceanu-1a requested a review from a team as a code owner April 16, 2024 13:14
Copy link

nx-cloud bot commented Apr 16, 2024

☁️ Nx Cloud Report

CI 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 targets

Sent with 💌 from NxCloud.

cpaulve-1A
cpaulve-1A previously approved these changes Apr 16, 2024

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');
Copy link
Contributor

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 ?

Copy link
Member Author

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

  1. fix all linter errors that are not fixable with lint --fix
  2. run the applyLintFix after app and lib generation and
  3. write IT tests to make sure there are no lint errors for apps and libs

Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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');
Copy link
Contributor

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

packages/@o3r/eslint-plugin/tsconfig.spec.json Outdated Show resolved Hide resolved
@vscaiceanu-1a vscaiceanu-1a force-pushed the bugfix/1661 branch 2 times, most recently from 76a0389 to dcf32fd Compare April 19, 2024 14:21
fpaul-1A
fpaul-1A previously approved these changes Apr 19, 2024
if (eslintFile.extends.indexOf(tsEslintParserDep) === -1) {
eslintFile.extends.push(tsEslintParserDep);
const eslintConfigOtter = '@o3r/eslint-config-otter';
if (eslintFile.extends.indexOf(eslintConfigOtter) === -1) {
Copy link
Contributor

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'

Copy link
Member Author

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vscaiceanu-1a vscaiceanu-1a added this pull request to the merge queue Apr 22, 2024
Merged via the queue into main with commit 33f2911 Apr 22, 2024
22 checks passed
@vscaiceanu-1a vscaiceanu-1a deleted the bugfix/1661 branch April 22, 2024 12:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: Linter does not work on a new Otter webapp in a monorepo
5 participants