-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: add api-extractor report #662
Conversation
b40299d
to
b549438
Compare
Codecov Report
@@ Coverage Diff @@
## master #662 +/- ##
==========================================
+ Coverage 72.94% 72.98% +0.04%
==========================================
Files 266 266
Lines 8618 8632 +14
Branches 1695 1697 +2
==========================================
+ Hits 6286 6300 +14
Misses 2293 2293
Partials 39 39
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM just a few comments.
@@ -16,7 +16,7 @@ | |||
* specific language governing permissions and limitations | |||
* under the License. */ | |||
|
|||
import { ComponentType } from 'react'; | |||
import React from 'react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this not work with selective imports?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the issue here is different, we should always import React
on TSX files to avoid issues with the api-extractor that's need that all files using JSX should import React in a consistent way microsoft/rushstack#1765
@@ -1,7 +1,7 @@ | |||
{ | |||
"compilerOptions": { | |||
"noUnusedLocals": true, | |||
"removeComments": true | |||
"removeComments": false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the extractor not work if this is set to true? If so I wonder if we should just have a separate tsconfig
for the API documenter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I came up with is the following:
we can first generate the declaration files with all the comments, and then we recompile again only generating the js (no declarations) with comments.
This will increase the build type, but also avoid any third party library that can touch the generated code in an unpredicted way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here the commit: b4edfa3
Codecov Report
@@ Coverage Diff @@
## master #662 +/- ##
=======================================
Coverage 72.60% 72.60%
=======================================
Files 266 266
Lines 8678 8678
Branches 1710 1710
=======================================
Hits 6301 6301
Misses 2338 2338
Partials 39 39
Continue to review full report at Codecov.
|
This commit adds comments to the generated declaration files but removes them from the compiled code. Unfortunately tsc doesn't do that by default, so we can only first generate the declaration with comments and then compile without
🎉 This PR is included in version 19.4.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Summary
This PR activates the api-extractor report allowing a semi-automated check about possible breaking changes on the current published API contract.
The extractor outputs a Markdown report file called
api/charts.api.md
. The following is an excerpt of that file:API Report File for "@elastic/charts"
This file shows all the public/beta/alpha type/interface/function exposed as part of our public API (visible when importing elastic/charts into a project).
It includes a set of warnings related to missing tags or wrongly used tags, for example:
The warnings in this example can be interpreted as:
AnnotationSpec
type is undocumented (no TSDoc is provided)@alpha
,@beta
,@public
) is missingTimeMs
, used by other exported types, is not exported by the main entry point.This PR adds also a GH workflow that runs the
yarn api:check
commands as a GH check and warns the PR author about possible changes of the current API document.Locally, you can run the same check running
yarn api:check --local
adding the--local
will automatically update theapi/charts.api.md
file.When this will be merged and during a PR review, it will be always required to take a careful look at the
api/charts.api.md
. If something breaks the existing contracts like a type declaration is changed, renamed, or removed then we should mark the PR as breaking change with a label.Future tasks:
breaking change
label if the API contract is brokenbreaking change
changelog and add that to the PR description