Seems like the null should be handled if the download fails and this returns null.

done

Kind of weird this doesn't just pass in the checksumDependencies map, but the null migration looks fine.

Are you sure packageName! is safe here?

1. it works
2. it seems to me like a bug we should fix if we don't know the packageName by this point

Is the null bool meaningful, or can this be

null means we haven't set it yet. This shouldn't be read before it's set, so I think late would make more sense.

made late

I've come around to @jonahwilliams's way of thinking about late (not late final): with few exceptions it should be avoided, except in tests. It usually points to some state needing to be known before the object is initialized, but we're setting it later, leaving the object in an invalid state. For example,

          final PubspecDependency? dependency = PubspecDependency.parse(line, filename: filename);
          if (dependency != null) { // We got one!
            // Track whether or not this a dev dependency.
            dependency.isDevDependency = seenDev;

could instead be:

          final PubspecDependency? dependency = PubspecDependency.parse(line, filename: filename, isDevDependency: seenDev);
          if (dependency != null) { // We got one!

class PubspecDependency extends PubspecLine {
  PubspecDependency(
    String line,
    this.name,
    this.suffix, {
    required this.isTransitive,
    required DependencyKind kind,
    required this.version,
    required this.sourcePath,
    required this.isDevDependency,
  }) : _kind = kind,
       super(line);

  static PubspecDependency? parse(String line, { required String filename, required bool isDevDependency }) {
...
    return PubspecDependency(line, package, suffix, isTransitive: isTransitive, version: version, kind: stripped.isEmpty ? DependencyKind.unknown : DependencyKind.normal, sourcePath: filename, isDevDependency: isDevDependency);

...
  final bool isDevDependency;

I've come around to @jonahwilliams's way of thinking about late (not late final): with few exceptions it should be avoided, except in tests. It usually points to some state needing to be known before the object is initialized, but we're setting it later, leaving the object in an invalid state. For example,

          final PubspecDependency? dependency = PubspecDependency.parse(line, filename: filename);
          if (dependency != null) { // We got one!
            // Track whether or not this a dev dependency.
            dependency.isDevDependency = seenDev;

could instead be:

          final PubspecDependency? dependency = PubspecDependency.parse(line, filename: filename, isDevDependency: seenDev);
          if (dependency != null) { // We got one!

class PubspecDependency extends PubspecLine {
  PubspecDependency(
    String line,
    this.name,
    this.suffix, {
    required this.isTransitive,
    required DependencyKind kind,
    required this.version,
    required this.sourcePath,
    required this.isDevDependency,
  }) : _kind = kind,
       super(line);

  static PubspecDependency? parse(String line, { required String filename, required bool isDevDependency }) {
...
    return PubspecDependency(line, package, suffix, isTransitive: isTransitive, version: version, kind: stripped.isEmpty ? DependencyKind.unknown : DependencyKind.normal, sourcePath: filename, isDevDependency: isDevDependency);

...
  final bool isDevDependency;

I agree with you that it is a code smell and that doing the parsing in a factory would be better. I would prefer to do refactors in a separate PR, lest I break something in them and it gets reverted. How about if I file a tracking issue to clean up this file?

Sure. Or don't and we can just fix it if it someday breaks. This is an internal-ish development feature we don't need to spend too much time on it.

Also the isDevDependency one could be done without much refactoring by just adding it to the constructor as in my code snippet. _lockIsOverride is trickier.

Can this be instantiated to avoid the late?

by making it late, we ensure that it has been initialized before reading it. Is there a valid reason to read this value before we've parsed the lockfile in parseLock()?

This one is trickier since (without a bigger refactor) it does seem to need to be set after initialization. "Not yet set" could be a nullable boolean, where null means it hasn't yet been parsed. It seems loaded to have a lockIsOverride interface that the consumer of the API needs to understand can only be called after another method? And that, for example describeForFakePubspec calls it, so you need to also never call that method unless you've called parseLock first? It's a confusing contract.
If I were to build it from scratch I might have parseLock not mutate itself, but instead produce a new object that has what we need, and properties for lockLine and lockIsOverride. But I haven't looked too closely at this.

However I get you want to minimize the refactoring, so follow your heart. In either case, it seems like _lockLine and _lockIsOverride should either both be nullable, or both be late.