findBreakingChanges yields `TYPE_REMOVED` when a single instance of a scalar is removed

[maxuuell]

An interesting behavior was found when playing around with findBreakingChanges between two schemas.

When two schemas are compared, with one of them having only one Int type, and the second removes the only Int type, the breaking changes array will show:

[ { type: 'TYPE_REMOVED',
    description: 'Int was removed.' },
{ type: 'FIELD_REMOVED',
description: 'User.age was removed.' } ]

Should this be two breaking changes? It seems odd to say removing the last instance of a scalar type would be a breaking change, as opposed to removing a defined object type.

Does that mean when a schema is created, it will strip out any scalars that aren't being used?

[IvanGoncharov]

Does that mean when a schema is created, it will strip out any scalars that aren't being used?

Yes, exactly that. We are in process of clarifying it in the spec:
https://github.com/graphql/graphql-spec/pull/597/files#diff-86a7cb172ae1d944ca3719bd848b1d8bR356-R359

When returning the set of types from the __Schema introspection type, all
referenced built-in scalars must be included. If a built-in scalar type is not
referenced anywhere in a schema (there is no field, argument, or input field of
that type) then it must not be included in the schema.

So technically you removed Int from your schema by removing User.age.
I don't think we should hide this fact but instead, I created #2204 to change this message to:

Standard scalar Int was removed because it is not referenced anymore.

@maxuuell What do you think?

[wtrocki]

So I can create a schema with only my types and once schema is created some additional scalars etc. will be added. Is there a method to strip out this additional element? Getting a config from existing schema will still contain them and I saw people doing this manually in community libraries.

It that is possible then this schema can be passed to compare method and it will produce diff only for what is specified in schema string, which some people might expect.

Without that filtering on changes is needed - an assessment that this scalar was my own or it was comming from core lib.,

[maxuuell]

@IvanGoncharov Thank you for clarifying and circling back. I think the newer message is fine.

[IvanGoncharov]

@wtrocki SDL is not a single representation of the spec, for example introspection contains definitions for all types (including standard scalars).
It would be strange if something suddenly disappears from introspection but wasn't reflected in findBreakingChanges. I agree that filtering would be a great addition but it should be disscuss in context of #2181