Phillip Lanclos

> Note to self: > > From the looks of it this is a straight extension on top of the jsx one: [c357387](https://github.com/standard/eslint-config-standard-react/commit/c357387937a7cfcaad33cbe6e3ac7f4a990d170d) > > > BREAKING: Stop extending from...

Can we just release this for now until we figure out the `jsx` vs `react` direction? I think it makes sense to consolidate those, but until that's done, I feel...

I would love this ability for paging with simple GraphQL with Postgres.

We ended up righting a function similar to `combineResolvers` from https://github.com/lucasconstantino/graphql-resolvers so we can just wrap any where clause and change the args before continuing. Similar to what's described there...

This is still a problem for us too. We don't want to use restore-keys because we would like to use `npm ci`. We would like to share node module caching...

+1 I installed this package thinking it would check my installed node/npm version. I think the current checks are useful, but adding that last check against the current installed node/npm...

Currently we are using this package along with https://github.com/kruppel/check-engines. I think adding that logic into node-installed-check would make sense and cover all the checks.

I think it can also improve readability as the reader's eyes always know where to look for the "what happens if" piece. I don't think it is just about being...

I can't believe you put semicolons in there. Are you even using standard? 😝 Yeah, I can def see those situations might be a good place for them as long...

Will the `unsafe` TS checks ever be added? They are recommended by `typescript-eslint` via `plugin:@typescript-eslint/recommended-requiring-type-checking` ``` '@typescript-eslint/no-unsafe-argument': 'error', '@typescript-eslint/no-unsafe-assignment': 'error', '@typescript-eslint/no-unsafe-call': 'error', '@typescript-eslint/no-unsafe-member-access': 'error', '@typescript-eslint/no-unsafe-return': 'error', ```