Eslint setup and fixes #197
Conversation
|
@matejfalat is attempting to deploy a commit to the wolfsociety-org Team on Vercel. To accomplish this, @matejfalat needs to request access to the Team. Afterwards, an owner of the Team is required to accept their membership request. If you're already a member of the respective Vercel Team, make sure that your Personal Vercel Account is connected to your GitHub account. |
matejfalat
requested review from
matejos and
memoriesadrift
and removed request for
matejos
src/pages/account.tsx
Outdated
| @@ -25,6 +25,7 @@ import { useAccount } from 'wagmi' | |||
| import { enqueueSnackbar } from 'notistack' | |||
| import { useRouter } from 'next/router' | |||
| import { signMessage } from '@/utils/wallet' | |||
| import { GetUserResponseData } from './api/user/[address]' | |||
There was a problem hiding this comment.
For some reason, I remember explicitly not wanting to import from api on the client, but I can't seem to find anything backing up exactly why... leaving this here as a note for now
There was a problem hiding this comment.
I don't really know about such limitation, but maybe import type {... would be better in this case, so that at least it's not imported during runtime? The idea here was to export the response / request types from api, so that we can assert the same types on client 🤔
There was a problem hiding this comment.
I would be more comfortable with import type, I'm pretty sure /api/ and the rest need to be separate for security reasons, though I can't find a reference :/
|
Since commit EDIT: Solved by deleting the whole |
matejfalat
force-pushed
the
technical-debt-fixes
branch
from
94e0f99 to
9629b68
Compare
Added more strict eslint config and fixing related eslint / TS errors, upgraded some packages and a few minor refactors I did back in August as a preparation for the project. Feel free to discuss or revert the changes 😉
A thorough testing should be probably done before merging/deploying, as I'm not that familiar with the project and might have missed some use cases.
The few remaining eslint errors are related to a mismatch between Contentful CMS models and the types as defined in the app. It would be nice to have the types generated from the Contentful models (it can be done with the https://github.com/contentful-userland/cf-content-types-generator library), however since the generated types don't quite match the currently used types (mostly differ in what properties are optional vs required), either the models would have to be updated in the CMS, or add handling of undefined properties throughout the app. If we're willing to do that, I can also provide the branch with the generated types.