Create an Ion Schema linter

[popematt]

It would be useful to have an opt-in tool to help enforce some best practices and avoid some common pitfalls. Individual rules should be able to be turned on or off.

Some possible linter rules, in no particular order:

• No wildcard imports (ie. types must be imported by name rather than importing a whole schema)
• The list of types of any_of, all_of, and one_of constraints should not have duplicate elements (see Clarify whether repeated type references are allowed for the sum-type constraints #53)
• The list of values for valid_values constraints should not have duplicate elements
• Type definitions should have at least one constraint
• Type definitions should not have repeated constraints (use logical constraints instead to combine things in more obvious ways)
• Schemas should have at least one type definition
• Type names should only/not have certain characters (eg. only [a-zA-Z0-9_$]+ or names may not contain whitespace)
• SchemaIds should only/not have certain characters

[popematt]

If the proposed solutions for #44 and/or #51 are incorporated into Ion Schema 2.0, it would be good to have linter rules to warn when an argument for that constraint would be unsatisfiable.

For example:

// annotations argument has unsatisfiable type
annotations: { valid_values: [ null.null ] }
annotations: { byte_length: 42 }

// field_names argument has unsatisfiable type
field_names: { scale: 42 }
field_names: sexp

This can be further generalized to warn (for all type definitions) when conflicting constraints are present.

// unsatisfiable combination of constraints
type::{
  name: foo,
  timestamp_precision: seconds,
  codepoint_length: range::[min, 50],
}

However, in all of these cases, one could argue that these should be invalid schemas instead of just eliciting a linter warning.

[popematt]

It would be a good idea to try to write some linter rules as Ion Schema. It's not possible to have a complete check for satisfiability that is written in pure Ion Schema, but it is possible for the rule about having incompatible constraint types in a single type definition to be modeled in ISL. I believe that most (if not all) of the other proposed rules could be expressed in a linter variant of ion-schema-schemas.

[popematt]

Another potentially useful linter rule—the upper and lower bound of a timestamp range should have the same offset (to avoid confusion).

Or, even stricter, the linter could also require that all timestamp ranges be written in UTC (i.e. an offset of either -00:00 or +00:00/Z).

[popematt]

Another potentially useful linter rule—some regexes are susceptible to catastrophic backtracking. It would be useful to have a way to identify and flag regex constraints that have susceptible patterns.

Possibly useful references:

• https://www.cs.utexas.edu/%7Eisil/redos.pdf
• https://github.com/tjenkinson/redos-detector
• https://github.com/NicolaasWeideman/RegexStaticAnalysis