We should generate a test which asserts that the rules_prerender and @rules_prerender/* NPM packages are the same version as the @rules_prerender workspace to avoid version skew.
This is tricky to do in practice, since currently there is nothing in the repository source which actually specifies the version number. I've tried to keep it that way because manual version bumps just introduce a lot of toil. I'm not entirely sure how to do this without manually managing versions, but one idea I have is:
At release time, inject the released version into the repository at a specific path.
When the user installs the workspace, generate a test which compares the version in the workspace against the NPM package versions and fail if they disagree.
This means that the released workspace doesn't 1:1 match the actual workspace source, but that might be a small enough difference to not matter? If you're depending on it through other means (such as a local checkout of the source installed via local_repository()), then I think it's fair to skip/not support this verification.
We should generate a test which asserts that the
rules_prerenderand@rules_prerender/*NPM packages are the same version as the@rules_prerenderworkspace to avoid version skew.This is tricky to do in practice, since currently there is nothing in the repository source which actually specifies the version number. I've tried to keep it that way because manual version bumps just introduce a lot of toil. I'm not entirely sure how to do this without manually managing versions, but one idea I have is:
@aspect_rules_jsrelease process to manually tar and release their own source code as an asset to the GitHub release.This means that the released workspace doesn't 1:1 match the actual workspace source, but that might be a small enough difference to not matter? If you're depending on it through other means (such as a local checkout of the source installed via
local_repository()), then I think it's fair to skip/not support this verification.