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

feat!: flat config + v9 support, rule unification, add TS config #14

Merged
merged 24 commits into from
Nov 7, 2024

Conversation

jirimoravcik
Copy link
Member

@jirimoravcik jirimoravcik commented Oct 11, 2024

This PR begins a new era of linting at Apify.
It introduces a new shared eslint config. It uses the flat eslint format and works with eslint v9.

I consolidated the TypeScript config into this one, so the maintenance and updates are easier. This means we won't need apify-eslint-config-ts anymore.

I have tried to consolidate most of the rules from configurations we have available across our projects. If you still feel something should be changed, feel free to comment here.

Newly added/enabled rules:
no-use-before-define
no-param-reassign
consistent-return
array-callback-return
no-promise-executor-return
@typescript-eslint/array-type
@typescript-eslint/adjacent-overload-signatures
@typescript-eslint/no-for-in-array
@typescript-eslint/no-implied-eval
@typescript-eslint/no-inferrable-types
@typescript-eslint/no-confusing-non-null-assertion
@typescript-eslint/prefer-includes
import/no-default-export

Let's first review this PR, then I'll release a beta version that can be easily tested 😉 .
After that, we'll do final touches and merge this PR. After that, we'll have to update the config across our projects. I will oversee this and create/plan tasks in GitHub for it.

@jirimoravcik jirimoravcik added the adhoc Ad-hoc unplanned task added during the sprint. label Oct 11, 2024
@github-actions github-actions bot added this to the 100th sprint - Platform Team milestone Oct 11, 2024
@github-actions github-actions bot added the t-platform Issues with this label are in the ownership of the platform team. label Oct 11, 2024
@jirimoravcik jirimoravcik marked this pull request as ready for review October 31, 2024 14:15
@jirimoravcik jirimoravcik removed the adhoc Ad-hoc unplanned task added during the sprint. label Oct 31, 2024
@jirimoravcik jirimoravcik changed the title feat!: flat config support feat!: flat config + v9 support, rule unification, add TS config Oct 31, 2024
// Require methods and fucnctions to be marked async if they return a Promise.
'@typescript-eslint/promise-function-async': 'error',
// Force the usage of "import type" for type imports.
'@typescript-eslint/consistent-type-imports': 'error',
Copy link
Member

Choose a reason for hiding this comment

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

Seems this defaults to fixStyle: 'separate-type-imports' which would error on import { type CheerioCrawlingContext } if I'm reading it right? We use that syntax in some places but I'm ok to be overturned :)

https://typescript-eslint.io/rules/consistent-type-imports/#fixstyle

Copy link

Choose a reason for hiding this comment

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

I hate import { type it feels messy and ends up having several types mixed between the imports as the file grows. Also apparently this is better performance 🤔

Copy link

Choose a reason for hiding this comment

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

I don't care, but having only one type seems good. I guess this can also be autofixed.

Copy link
Member

Choose a reason for hiding this comment

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

We use import { type quite extensively, because we have some other rule set up in a way that we can only have one import per file/dependency, but if the fixer works, I really don't mind.

I recall those fixers tend to screw up with whitespace, but maybe it was a different rule than this one.

Copy link
Member

@fnesveda fnesveda left a comment

Choose a reason for hiding this comment

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

Very cool! Just a few small points.

package.json Outdated Show resolved Hide resolved
index.js Outdated Show resolved Hide resolved
index.js Show resolved Hide resolved
index.js Outdated Show resolved Hide resolved
jirimoravcik and others added 2 commits November 1, 2024 14:31
Co-authored-by: František Nesveda <[email protected]>
Co-authored-by: František Nesveda <[email protected]>
index.js Outdated Show resolved Hide resolved
index.js Show resolved Hide resolved
index.js Show resolved Hide resolved
index.js Show resolved Hide resolved
index.js Show resolved Hide resolved
index.js Outdated Show resolved Hide resolved
index.js Outdated Show resolved Hide resolved
// Require methods and fucnctions to be marked async if they return a Promise.
'@typescript-eslint/promise-function-async': 'error',
// Force the usage of "import type" for type imports.
'@typescript-eslint/consistent-type-imports': 'error',
Copy link

Choose a reason for hiding this comment

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

I don't care, but having only one type seems good. I guess this can also be autofixed.

Copy link
Member

@B4nan B4nan left a comment

Choose a reason for hiding this comment

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

sorry for the late review, way too many adhoc things

package.json Outdated Show resolved Hide resolved
.github/workflows/publish.yaml Outdated Show resolved Hide resolved
.github/workflows/publish.yaml Outdated Show resolved Hide resolved
.github/workflows/publish.yaml Outdated Show resolved Hide resolved
Comment on lines 29 to 31
git_tag=v`node -p "require('./package.json').version"`
git tag $git_tag
git push origin $git_tag
Copy link
Member

Choose a reason for hiding this comment

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

why not use npm version instead which will handle both git tag and bumping? this feels like you only deal with publishing and once released, things will fall apart unless someone bumps manually.

note that npm version should be used before npm publish

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 bumping should be done manually, yes.

Copy link
Member

Choose a reason for hiding this comment

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

I really dislike that, the new release process we are adopting these days don't suffer from this unnecessary manual step, why should we deal with this manually here? Basically all our public repos (except CLI which is in progress) don't requite this now, we release via workflow dispatch and bump based on conventional commits with possible manual override. We could adopt the same in here if you want, I'd let @janbuchar to make it work since its all his work. It also means automated changelogs and GH releases and other goodies.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, nice. Please send me some PR/commit that implements it, I'll do it here. Thanks!

Copy link
Member

Choose a reason for hiding this comment

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

One from the CLI, we have also canary builds in there, I don't know what we want from this repo, we could as well just ship to stable like we do in apify-shared-js, but if we want beta versions and stable releases via workflow dispatch, that's what the CLI and client are doing.

apify/apify-cli#691

In client we had two PRs since we missed one thing

apify/apify-client-js#596
apify/apify-client-js#605

index.js Outdated Show resolved Hide resolved
Comment on lines +108 to +113
groups: ['builtin', 'external', ['parent', 'sibling'], 'index', 'object'],
alphabetize: {
order: 'asc',
caseInsensitive: true,
},
'newlines-between': 'always',
Copy link
Member

@B4nan B4nan Nov 6, 2024

Choose a reason for hiding this comment

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

I am personally a bit allergic to this mixed quoting, but I guess it's better for not producing unnecessary git diffs...

(this is not about the rules highlighted, but about the quoting on the keys)

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 don't follow

Copy link
Member

Choose a reason for hiding this comment

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

alphabetize is not quoted but 'newlines-between' is

// Allow less strict formatting of function parentheses.
'function-paren-newline': 'off',
// Prefer destructuring for certain cases only. Forcing destructuring for arrays can make the code less readable.
'prefer-destructuring': ['error', {
Copy link
Member

Choose a reason for hiding this comment

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

(personal pet peeve)

If I could change one thing in how we write things in Apify, it would be this. We overuse (object) destructing so hard in here 😿

Copy link
Member Author

Choose a reason for hiding this comment

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

Can you provide some examples, where you feel we overuse destructuring?

Hmm, wondering if the correct word is destructuring or destructing

Copy link
Member

Choose a reason for hiding this comment

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

All the open source repos had this enabled and use it extensively, same for actors. My problem with this is that you loose discoverability, as well as ability to mutate things. Wanna see what is available in actor context? You need to go to the function params instead of just writing ctx.. Wanna change some option we destruct on runtime? Sorry, cant do, since we introduced a new local var for it and used that instead. Also it feels like it results in more code while it was (imho) introduced to make us write less. Lastly, it forces people to do weird things like destructing process.env, which again suffers from the immutability, making tests of env vars much harder.

But maybe its just me 🙃

Copy link

@Strajk Strajk Nov 7, 2024

Choose a reason for hiding this comment

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

loose discoverability, as well as ability to mutate things

sorry for stalking but :this: 💯 👍

Choose a reason for hiding this comment

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

I generally think that immutability is good, but the loss of discoverability is real. Reading the choose-your-adventure style code is a pain.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm, wondering if the correct word is destructuring or destructing

Oh lord, I have been calling it wrong the whole time, thanks for mentioning :D

},

rules: {
indent: ['error', 4, {
Copy link
Member

Choose a reason for hiding this comment

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

this is quite buggy (and deprecated) rule, it screws up with decorators (which is valid for the console nest app), they had quite a lot of issues about this, closed as wontfix, suggesting people to use formatters instead of it

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, formatting will be the next step, but it would make scope of the project too large, so I'll keep it here until we move forward with prettier in the future

Copy link
Member

Choose a reason for hiding this comment

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

yes, my point is we should not use this rule, not that we should add prettier right ahead. its broken and console team will have issues with that in the nest repo most likely.

index.js Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
@jirimoravcik
Copy link
Member Author

jirimoravcik commented Nov 7, 2024

Hello @janbuchar I borrowed the nice release actions you made for Apify client. Can you check that they're setup alright here? I've done 2 changes: Removed wait for checks step and removed build step (before publish). Thanks

FYI the 2 secrets used are inherited from org so they should be available.

Also one question, will it behave ok since we don't have package-lock.json in this repo? and also no CHANGELOG.md?

Copy link

@janbuchar janbuchar left a comment

Choose a reason for hiding this comment

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

@jirimoravcik yeah, I believe it will work fine.

Comment on lines +52 to +57
- name: Update CHANGELOG.md
uses: DamianReeves/write-file-action@master
with:
path: CHANGELOG.md
write-mode: overwrite
contents: ${{ needs.release_metadata.outputs.changelog }}

Choose a reason for hiding this comment

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

If you don't want to keep a changelog for some reason, then you can delete this. Same applies to release.yaml.

.github/workflows/release.yaml Outdated Show resolved Hide resolved
.github/workflows/pre_release.yaml Outdated Show resolved Hide resolved
@jirimoravcik jirimoravcik merged commit e09b4e7 into master Nov 7, 2024
1 check passed
@jirimoravcik jirimoravcik deleted the feat/flat-config-support branch November 7, 2024 15:24
@fnesveda fnesveda added the validated Issues that are resolved and their solutions fulfill the acceptance criteria. label Nov 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
t-platform Issues with this label are in the ownership of the platform team. validated Issues that are resolved and their solutions fulfill the acceptance criteria.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants