Code generation with static errors

[Rodsevich]

Describe the bug
I ran the code generator in my package with the lints from VGV (include: package:very_good_analysis/analysis_options.6.0.0.yaml in analysis_options.yaml) enabled and this happened:

The violations can be ignored through:

• argument_type_not_assignable
• avoid_dynamic_calls
• return_of_invalid_type

To Reproduce
Steps to reproduce the behavior:

1. Go to analysis_options.yaml
2. Add this:

analyzer:
  language:
    strict-casts: true

3. See errors

Expected behavior
The ideal would be to respect the strict casts, I think that's possible. But otherwise by just adding those ignores to the generated files the thing would be enough.

Example PR
If I find the time in some weeks I create a PR. Thanks a lot for the package btw, you are genius!

[jpeiffer]

TLDR; I'm going to close this issue as a "won't fix". A PR to address the lints or even one to add them as ignores would be great and either would be merged. Next comes the "why"...

---

The swap from dynamic to a stronger type would greatly complicate the generated code. If someone's willing to do that work, I'm open to a PR to bring it in.

The first problem comes down to the operator function within Dart. Let's say I took a Map? in as the argument. That's great, but it really only needs the [] operator. I know of a multiple times where the [] operator was implemented but Map was not extended.

Here's a couple examples:

• args -- the parsed args are a non-map object, but it uses the [] operator.
• sqflite -- the result set is a non-map object, but it uses the [] operator.

I've encountered others but can't remember them offhand. I've personally found it handy to be able to take the results of these non-Map objects and pass them along. They don't always have a way to iterate the keys so the idea of forcing the dev to regenerate them as a Map ends up precluding these packages as inputs and I'm not a big fan of that idea.

So let's say those problems could be solved and a Map<String, Object?>? really could be used. Let's ask, what is the Object?. It always can be a String. It sometimes can be a double, a int, a bool, another Map, or even a List. But it can also whatever object the decoder ultimately needs like a X Function<X, Y>(Y input). Those types of things are really difficult to suss out in the generation code, which itself is frustratingly difficult to debug.

Finally, the easier fix... I don't use those rules, so I'm not going to bother to add them. But if you'd like to, I'd be happy to merge that PR because I can't see any possible harm in that change. Just... if you go that route, please ensure they are in alphabetical order. I'm pretty picky about that. 😁