Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
The project should better demarcate what is API and what is not
See original GitHub issueCurrently it is not crystal clear what is API and what is not.
Clearly top level classes such as GraphQL and ExecutionStrategy are API
But what about graphql.execution.Execution or graphql.execution.ValuesResolver. Are they API or implementation detail?
If we had to add new aspects to these classes and changed constructors etc are we breaking consumers?
I suggest that the API be made more clear.
Annotations are a great way to do this. The project could have 3 new annotations
@PublicAPI (things you can call and wont change) @PublicSPI (things you are meant to implement) @Internal (public things that are not API and may change)
This will allow the project to better keep semver sematics while evolving as necessary.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:4
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I agree on .internal in the package name as well as .api in the packages however that would be a major breaking change.
Ideally it would be
and
the use of annotations are a way to not break current API while better documenting what is API
regarding
@Internali think puttinginternalin package name is a good practice