Description
Is your feature request related to a problem? Please describe.
It's very easy to start using Internal JavaScript API's, and that means the solution can break on any upgrade (including patches). For Deprecated API's it's best to fix them ASAP so there's less work when upgrading to a new major. It's hard to detect this without reading the documentation or looking for runtime browser console messages.
Describe the solution you'd like
I've written a tool to create a simple report. It doesn't require any changes to the code anywhere, and can be run on any environment with node (or yarn): yarn create @episerver/cms-api-report or npx @episerver/create-cms-api-report.
> yarn create @episerver/cms-api-report
yarn create v1.19.1
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Installed "@episerver/[email protected]" with binaries:
- create-cms-api-report
API Module name Usages
internal epi-cms/command/_NonEditViewCommandMixin 1
internal epi-cms/compare/views/SideBySideCompareView 1
internal epi-cms/component/command/_GlobalToolbarCommandProvider 1
internal epi-cms/contentediting/CreateContent 1
internal epi/shell/StickyViewSelector 1
internal epi/shell/layout/AnimatedCardContainer 1
internal epi/shell/widget/SearchBox 1
�💣 Deprecated API's used 0 times
⚠️ Internal API's used 7 times
Maybe it can be used in the build pipeline (although I recommend my alternative solution for that).
Describe alternatives you've considered
That report generator is just a nice wrapper around a ESLint plugin called eslint-plugin-episerver-cms to get people started and see if they should be linting continously. Ideally you should be using ESLint to lint your JS files (maybe even use the CMS UI team's base config?), with the plugin. Then just have eslint . as part of the build or test steps.
Another benefit is if you have a ESLint extension to your IDE installed, you get syntax highlighting like this:
Additional context
It's on the backlog to move these tools to the Episerver repo, but they're under the @episerver scope on npm so you wouldn't have to change anything if you adopt it before the move.