hey team, is there any tooling around writing lint...

# apollo-kotlin

[agrosner]

hey team, is there any tooling around writing lint checks in graphql files for apollo? specifically this situation: We’re using a CacheKeyGenerator to formulate caching keys for complex entities that have multiple forms of identity.
• id - can be an entity with a fully formed id based on @key field of the entity itself

type SomeEntity @key(fields: "id") {
  id: ID!
}

• if no id, then use another secondaryId field in combination with the complex entity, call it foo

type SomeEntity @key(fields: "secondaryId foo { id }") {
  secondaryId: Int
  foo: Foo
}

• if foo not found, then use secondaryId only if found.
• if none found, fallback on TypePolicyCacheKeyGenerator
now the main issue is that there is no way to enforce developers follow this format and query for those fields if available to ensure its properly cached.

if we query for something that may have an id or second option with combination key, but only for the title and secondaryId, but not the nested id that we need:

theEntity {
  title
  secondaryId
}

then our entity that gets normalized forgoes uniqueness on the foo level, leading to overwriting and sharing of the same entity, even if unintentionally.

[agrosner]

is the alternative using a declarative type policy for every entity the only way to go?

[wasyl]

the main issue is that there is no way to enforce developers follow this format and query for those fields if available to ensure its properly cached.

the latter we're doing with graphql-eslint and its require-selections rule I think, + you can write your own if you have custom things you want to enforce

https://the-guild.dev/graphql/eslint/docs
https://github.com/dimaMachina/graphql-eslint/blob/master/packages/plugin/src/rules/require-selections.ts

[wasyl]

actually we're using require-id-when-available rule (you can configure required fields) but I don't see it in the sources for some reason. Maybe the name has changed

[agrosner]

Ohh interesting, but that requires using eslint 😞

[agrosner]

I’d probably have to write a custom gradle task to check, whereas I’d love ide integration too, it might be a larger task to get something natively spun up

[agrosner]

The alternative is to just add all possibilities as declarative cache types and then fallback on default cache normalization when not used . Originally we had issues with tooling to register queries in our system used a separate tool written in node that read our raw GraphQL files without Apollo code gen. Now we’re moving to operation manifests and will need to use Apollo tooling anyways. So I think without a standard way to lint the code without needing eslint, declarative cache is probably the way to go forward to prevent mistakes