-
Notifications
You must be signed in to change notification settings - Fork 0
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
Conversation
// 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', |
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.
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
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.
I hate import { type
it feels messy and ends up having several type
s mixed between the imports as the file grows. Also apparently this is better performance 🤔
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.
I don't care, but having only one type seems good. I guess this can also be autofixed.
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 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.
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.
Very cool! Just a few small points.
Co-authored-by: František Nesveda <[email protected]>
Co-authored-by: František Nesveda <[email protected]>
// 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', |
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.
I don't care, but having only one type seems good. I guess this can also be autofixed.
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.
sorry for the late review, way too many adhoc things
.github/workflows/publish.yaml
Outdated
git_tag=v`node -p "require('./package.json').version"` | ||
git tag $git_tag | ||
git push origin $git_tag |
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.
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
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 bumping should be done manually, yes.
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.
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.
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.
Ok, nice. Please send me some PR/commit that implements it, I'll do it here. Thanks!
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.
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.
In client we had two PRs since we missed one thing
groups: ['builtin', 'external', ['parent', 'sibling'], 'index', 'object'], | ||
alphabetize: { | ||
order: 'asc', | ||
caseInsensitive: true, | ||
}, | ||
'newlines-between': 'always', |
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.
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)
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.
I don't follow
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.
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', { |
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.
(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 😿
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.
Can you provide some examples, where you feel we overuse destructuring?
Hmm, wondering if the correct word is destructuring or destructing
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.
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 🙃
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.
loose discoverability, as well as ability to mutate things
sorry for stalking but :this: 💯 👍
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.
I generally think that immutability is good, but the loss of discoverability is real. Reading the choose-your-adventure style code is a pain.
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.
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, { |
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 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
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.
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
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.
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.
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 |
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.
@jirimoravcik yeah, I believe it will work fine.
- name: Update CHANGELOG.md | ||
uses: DamianReeves/write-file-action@master | ||
with: | ||
path: CHANGELOG.md | ||
write-mode: overwrite | ||
contents: ${{ needs.release_metadata.outputs.changelog }} |
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.
If you don't want to keep a changelog for some reason, then you can delete this. Same applies to release.yaml
.
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.