Pub: Consider warning about unrecognized fields when parsing pubspecs

[jakemac53]

The pubpsec parser has to be lenient to allow for any old pubspec to be properly parsed, but this provides negative value at development time because simple spelling mistakes cause sections to be skipped instead of giving errors or warnings.

This came up recently with the sdk constraints in gitter - a user was confused about where to put the constraint, partly because this page is misleading (it omits the environment key).

Another common mistake is misspelling dev_dependencies or dependency_overrides, or using the singular version of those (I have seen googlers do this several times in person).

My initial though is to emit a warning message about unrecognized fields by default (but not fail). We could also hide it behind a separate command but that would have far less value as it wouldn't be very discoverable.

We could also add a --strict flag that causes it to actually fail on unrecognized fields.

Thoughts?

[zoechi]

What should happen with additional fields supported by Flutter?
(My personal opinion is that these Flutter-specific things shouldn't be in pubspec.yaml in the first place but probably won't be changed)

[natebosch]

What should happen with additional fields supported by Flutter?

That's a good callout - we could ignore those as well but it does introduce a point of coupling that is sub-optimal...

[jakemac53]

I wonder if flutter would be willing to modify pub in their version of the sdk to support parsing those fields, then they would maintain/own the logic for it at least.

[natebosch]

Synced a bit offline - I think what we'd like to do is this:

• Add support for a configuration file within the SDK where flutter can tell pub which top-level keys to ignore during validation.
• Add in some light validation for specific non-top-level keys like sdk or flutter within environment. We already have decent validation for stuff like dependencies.
• Add in a check for any top-level keys we don't recognize and aren't configured in the SDK to get ignored.

cc @tvolkert - do you anticipate any pushback against adding a pubspec validation configuration file within the flutter SDK?

[natebosch]

looking again - I guess flutter already nests everything under flutter so we could ignore that entirely and skip the complexity of an extra configuration file...

[tvolkert]

/cc @Hixie

[Hixie]

So long as the flutter key doesn't trigger an error, I think we're happy to manage the maintenance and validation of the flutter section of the pubspec.yaml in the flutter tool itself, and would welcome the pub tool validating everything else.

(We used to have a separate flutter.yaml but it was a source of endless issues until we moved everything into the pubspec.yaml file.)

[Hixie]

(FWIW, we do some validation of the flutter section already. The schema is at https://github.com/flutter/flutter/blob/master/packages/flutter_tools/schema/pubspec_yaml.json, the validation code is at https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/flutter_manifest.dart.)