Skip to content

fix(lib): reject blank targetVersions ranges #458

Description

@sakul-learning

Description

A blank or whitespace-only range in targetVersions is accepted as valid and then treated as if that product were not declared. This lets synth-time feature checks silently skip a targeted product.

This was discovered while reviewing the ValidateFeatureTargetSupport migrations in #453, #454, #455, and #456. It is a shared validation issue rather than a defect specific to any one of those PRs, so it should be fixed separately.

Reproduction

Configure an app with an empty Terraform range:

{
  "targetVersions": {
    "terraform": ""
  }
}

Then use a feature whose Terraform availability is validated through ValidateFeatureTargetSupport, such as an import block requiring Terraform >=1.5.0.

The app synthesizes without the expected compatibility error.

Whitespace-only values such as " " and "\t" behave the same way.

Cause

The shared target-version validation accepts these values because npm semver normalizes blank and whitespace-only strings to the wildcard range "*":

semver.validRange("")  // "*"
semver.validRange(" ") // "*"

Later, checkFeatureSupportedByTargets() reads the original string and skips falsy ranges:

const targetRange = targets[product];
if (!targetRange) continue;

For "", validation therefore succeeds but the feature check treats the product as absent.

Expected behavior

A declared product must have a non-blank semver range. Empty and whitespace-only values should produce a configuration/validation error rather than disabling feature validation.

Suggested scope

  • Reject blank and whitespace-only ranges in the shared targetVersions validation/resolution paths.
  • Ensure checkFeatureSupportedByTargets() distinguishes an omitted product from a present-but-invalid value rather than relying on truthiness.
  • Add shared regression tests for both "" and a whitespace-only value.
  • Add one caller-level regression proving that a synth-time feature check cannot be bypassed with a blank range.

This should be handled in a separate PR; the individual feature-migration PRs do not need to absorb the shared fix.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions