NNBD migration

[dcharkes]

When NNBD goes to beta, we can start migrating this package, and release a dev version that is null-safe.

See roadmap: https://medium.com/dartlang/announcing-sound-null-safety-defd2216a6f3.

[vaind]

Looking forward to this, now that it is in beta.

$ pub upgrade
Resolving dependencies...
Because every version of ffigen depends on ffi ^0.1.3 and objectbox depends on ffi ^0.2.0-nullsafety.0, ffigen is forbidden.
So, because objectbox depends on ffigen ^1.1.0, version solving failed.

[dcharkes]

@mannprerak2 NNBD is in beta. We've been publishing pre-releases, see for example https://pub.dev/packages/ffi/versions. So we can go ahead and start on this.

[mannprerak2]

We still have 3 dependencies which haven't yet migrated to null-safety:

• package:pub_semver
• Nullsafe version on pub args#153
• Publish 2.0.0-nullsafety.0 glob#44

The following packages cannot be migrated due to failure in version resolving caused by package:test

• https://pub.dev/packages/yaml
• https://pub.dev/packages/logging

[dcharkes]

cc @jonasfj for package:pub_semver
cc @munificent for package:args & package:glob

[dcharkes]

Update:
https://pub.dev/packages/glob/versions/2.0.0-nullsafety.0
https://pub.dev/packages/pub_semver/versions/2.0.0-nullsafety.0

package:args does not have an NNBD version yet: https://pub.dev/packages/args/versions

@mannprerak2 we can actually address generating null-safe code (maybe behind an option for now) without migrating this repo itself to NNBD. That way people can use this package in a standalone way to generate NNBD safe code for their NNBD safe packages.

[mannprerak2]

@dcharkes adding this behind an option seems a little redundant to me (adding this option and then later on removing it), if the users have to be using this as a standalone, perhaps we can simply do a partial migration?

[vaind]

Shouldn't you be able to do the migration, with a couple of nullchecks/asserts (?, !) on the args and results of package:args functions you're using? Assuming your usage of package:args isn't too much, that should be manageable and later on when it's migrated, you just update the few calls. From ffigen users perspective, nothing would change.

[mannprerak2]

@vaind We can do a partial migration.
Here are the dependencies we can update in ffigen (as of now)-

dependencies:
  ffi: ^0.2.0-nullsafety.1
  yaml: ^3.0.0-nullsafety.0
  meta: ^1.3.0-nullsafety.6
  path: ^1.8.0-nullsafety.3
  quiver: ^3.0.0-nullsafety.2
  args: ^1.6.0        # Restricted by - test->analyzer->args
  logging: ^0.11.4    # Restricted by - test->coverage->logging
  cli_util: ^0.2.0    # Restricted by - test->analyzer->cli_util
  glob: ^1.0.3        # Restricted by - test->analyzer->glob
  pub_semver: ^1.4.4  # Restricted by - test->analyzer->pub_semver

dev_dependencies:
  pedantic: ^1.10.0-nullsafety.3
  test: ^1.16.0-nullsafety.13