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
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.
The text was updated successfully, but these errors were encountered:
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:
@aspect_rules_js
release 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.The text was updated successfully, but these errors were encountered: