You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason is that the analysis needs to parse code comments from the external library in order to determine basic properties, such as whether an API is marked as @beta or not. However, there's a LOT of junk in the node_modules folder, so we would not want to assume the tags have the meanings we expect, without some indicator that the library was built for API Extractor. In API Extractor 7 this requirement would apply to all analysis, not just .d.ts rollups. It's a little cumbersome, though.
@iclanton and I discussed this today and came up a with a better design: When API Extractor runs, it outputs a file such as dist/api-metadata.json which describes the version of API Extractor and some other basic information about the run. This file would NOT be added to Git, but would be published as part of the NPM package.
This will tell API Extractor that it is safe to parse and use TSDoc tags that it finds it the code comments for .d.ts files belonging to that package.
It also avoids the need to publish the .api.json files, which are quite large, and sometimes contain information that is not meant to be public.
The text was updated successfully, but these errors were encountered:
API Extractor 6 required you to add a
tsdoc
field like this to your package.json if you are using .d.ts rollups:The reason is that the analysis needs to parse code comments from the external library in order to determine basic properties, such as whether an API is marked as
@beta
or not. However, there's a LOT of junk in the node_modules folder, so we would not want to assume the tags have the meanings we expect, without some indicator that the library was built for API Extractor. In API Extractor 7 this requirement would apply to all analysis, not just .d.ts rollups. It's a little cumbersome, though.@iclanton and I discussed this today and came up a with a better design: When API Extractor runs, it outputs a file such as dist/api-metadata.json which describes the version of API Extractor and some other basic information about the run. This file would NOT be added to Git, but would be published as part of the NPM package.
This will tell API Extractor that it is safe to parse and use TSDoc tags that it finds it the code comments for .d.ts files belonging to that package.
It also avoids the need to publish the .api.json files, which are quite large, and sometimes contain information that is not meant to be public.
The text was updated successfully, but these errors were encountered: