There are too many changes in this PR. some of which may break the project at runtime (unlikely that 100% of functionality is tested in an automated manner...)
Prettier version change should be done in a seprate PR as it touches dozens of file and makes reviewing the PR diffcult.
Changing the TypeDoc output folder should be done ina separate PR as once again it touches many files.
do the github pages settings need be adjusted after you moved the generated sources?
did you test the generated webpage locally?
minor/patch version updates should be handled differently than major version changes.
Also dev-deps vs deps changes may need different handling.
updating CI images should likely be done separatly (if we need to revert it).
Updating our peerDeps should likely be considered a breaking change.
In regards to point 3 above:
patch/minor version changes are generally safe.
dev-deps updates (even major) are generally safe, as long as we release a new version and test it afterwards
major changes in Deps section should be done carefully (if at all) as they can include breaking changes.
In regards to our next version number:
We have to consider if we have any breaking change caused by this change, for example if we upgraded a 3rd party
library that dropped support for nodejs 12, maybe we should update the engine field in package.json and go up one major version too, (and expose the info on our new breaking change to the consumers).
There are too many changes in this PR. some of which may break the project at runtime (unlikely that 100% of functionality is tested in an automated manner...)
Prettier
version change should be done in a seprate PR as it touches dozens of file and makes reviewing the PR diffcult.In regards to point 3 above:
In regards to our next version number: