Comparison with prior art

[dandv]

Since this package was created well after similar packages, it would be nice to mention in the README the reasons for authoring it, and to guide users in choosing the right package for their situation.

When I'm comparing solutions, the ones that mention other projects and how they differentiate, win.

That's because those authors show awareness of existing alternatives, and likely have learned from their mistakes. Also as a user, I can better decide which tool is best for the job, and I appreciate the author's thoughtfulness in comparing the solutions in the space.

[dandv]

Pasting here the comparison from the issue linked above, in case this was closed accidentally:

What I was missing in original graphql-fields is fields transformation. For example, GraphQL API contains "id" field, but I need to query "_id" field in MongoDB, with the lib I did you can do it as configuration and do not need extra-code. So my lib differs in a way that it provides not only data extraction from GraphQLResolveInfo object, but also has fields name transformation API.

Also the difference is that fields map functionality returns tree which has false value on it's leafs which simplifies recursive traversal in some cases...

And one more thing - it gives an ability to fetch only a sub-tree of fields by a given path...

As well one more thing is that it provides ability to skip some paths from a resulting fields map tree to be returned, using wildcard patterns as well.

At least, all those were differences on the moment of creation of the library...

Also note that the graphql-fields author himself recommends graphql-parse-resolve-info instead.

[Mikhus]

This wasn't close by accident. Docs contains explicit library features description, and I see no reason to do any comparison with other libraries, as long as each library has it's own way of development and I have no will to maintain up-to-date comparison with any of them.