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

chore: use Biome as linter #111

Merged
merged 9 commits into from Dec 21, 2023
Merged

chore: use Biome as linter #111

merged 9 commits into from Dec 21, 2023

Conversation

ematipico
Copy link
Member

Changes

This PR uses Biome as linter. I applied safe and unsafe fixes. I suppressed some rules where we don't have enough information or where things were already suppressed with eslint.

Testing

Current CI should work

Docs

N/A

Copy link

changeset-bot bot commented Dec 20, 2023

⚠️ No Changeset found

Latest commit: 8b5959f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Member

@alexanderniebuhr alexanderniebuhr left a comment

Choose a reason for hiding this comment

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

@ematipico Thanks for taking the time and helping with this!
I'm in favor of this and thing it is great. 🚀

All the changes lgtm!

However, I would like to see that we replace eslint completely. Can you give some more reasons, why we still need eslint?

"enabled": true,
"rules": {
"suspicious": {
"noConsoleLog": "off",
Copy link
Member

Choose a reason for hiding this comment

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

Can we still get a warn?

Copy link
Member Author

Choose a reason for hiding this comment

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

You would get a bunch of warnings, which are annoying I felt annoying. Ideally, we could use an override, but they are currently buggy. Are you still happy with a warning?

Copy link
Member

Choose a reason for hiding this comment

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

Hm that is a tricky one. In general we don't really want to use console.log() for anything user-facing, everything user-facing should probably use astro's logger or error. So getting a warning, sounds feasible. However I was also annoyed by it before, so disabling this makes also sense.

I'm happy both ways, so maybe keep it off for now!

"rules": {
"suspicious": {
"noConsoleLog": "off",
"noExplicitAny": "off"
Copy link
Member

Choose a reason for hiding this comment

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

What is the reason to disable this rule?

Copy link
Member Author

Choose a reason for hiding this comment

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

There are a bunch of any that I didn't want to touch, so I turned off the rule. How do you want to proceed?

Copy link
Member

Choose a reason for hiding this comment

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

Oh I didn't know we had them :/
Let's keep the rule off for now, and I'll double check the code, to get rid of those anys

package.json Show resolved Hide resolved
@@ -21,6 +21,7 @@ export const createExports = (manifest: SSRManifest, _args: Args) => {
let locals: Record<string, unknown> = {};

if (request.headers.has('x-astro-locals')) {
// biome-ignore lint/style/noNonNullAssertion: safe because we checked before
Copy link
Member

Choose a reason for hiding this comment

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

I would love if typescript would be able to handle those checks on Maps....

Copy link
Member Author

Choose a reason for hiding this comment

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

I can change the code. The .get method returns undefined, so we can check the result. We wouldn't need the bang operator

Copy link
Member Author

Choose a reason for hiding this comment

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

Done in 0b9fc0e (#111)

Copy link
Member

Choose a reason for hiding this comment

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

Oh yeah that would work, I think rewriting the code makes sense.

I just think Typescript should support Map's .has()

@ematipico
Copy link
Member Author

ematipico commented Dec 21, 2023

Can you give some more reasons, why we still need eslint?

Unfortunately, Biome linter isn't on par with typescript-eslint because it cannot retrieve type information. Hence, I advise keeping it, but only the rules that require type information. For the rest, I think you can rely on Biome.

@alexanderniebuhr
Copy link
Member

[...] Biome linter isn't on par with typescript-eslint [...], I advise keeping [eslint], but only the rules that require type information. For the rest, I think you can rely on Biome.

Alright, sounds good for me. I really would love to get rid of eslint, I wonder how valuable those rules with type information are, but nothing to worry about in this PR!

@ematipico
Copy link
Member Author

I wonder how valuable those rules with type information are

One that I deem really important is: https://typescript-eslint.io/rules/no-floating-promises/

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.

None yet

2 participants