Add statement about possibility of source map rejecting in case of an invalid version field

[JSMonk]

I'm not quite sure about can be rejected instead of should be rejected, but I feel there should be freedom for choosing such behavior for tooling, but it is discussable.
Want to hear your opinions @mitsuhiko @littledan @jkup

[nicolo-ribaudo]

My opinion here is that we should enforce rejection as if it was, for example, an encoding error. There is a risk that one day in the future there will be a new source map version, and we should avoid source map v3 tools to accidentally consume a source map v(future) and provide wrong-but-not-rejected results.

[bomsy]

Also should we be specific about backward compatibility as well? E.g Implementations with support for v4 should still accept versions v3.

[littledan]

How about "must"?

[littledan]

Also should we be specific about backward compatibility as well? E.g Implementations with support for v4 should still accept versions v3.

I don't think we're going to do any more version number increments.

[mitsuhiko]

I would recommend to treat it as an error in the file, but I would not go as far as mandating a particular rejection, at least not for all consumers of a source map. It should however not be considered a valid source map.

(Which goes a little bit into what a tool should be doing for invalid source maps and quite frankly my recommendation would be to still try to apply it, even if there are issues with it.)

[JSMonk]

It sounds like a topic to discuss on one of the upcoming meeting.

[littledan]

...which must always be the number 3 as an integer. The source map may be rejected in case of a value different from 3.

[JSMonk]

Done ✅

[jkup]

Going to merge this. If, in the future, we realize there are multiple invalid fields that consumers try to recover, we should consider making a top level note that consumers may try to recover invalid source maps.