Migration to null safety

[Jonas-Sander]

Is there already a plan to migrate this library to null safety?

[MisterJimson]

Related PR #496

Not sure when it will be published

[tusharojha]

@mit-mit when we should expect the null safety version of this package on pub.dev?

Since I am looking to upgrade my package web_scraper to null safety but that depends on the http & html package. If you have any workaround then let me know.

[MisterJimson]

I am also blocked on finishing a migration of a package.

[robrbecker]

Any update on this? It is the highest blocking package according to https://github.com/dart-lang/sdk/wiki/Null-safety-migration-status

[enyo]

It seems as if the master already contains a null safe implementation. Any reason this hasn't been published yet?

[MisterJimson]

Quick update on this on Twitter: https://twitter.com/kevmoo/status/1340382649366429696?s=20

Basically, its being tested with internal Google code before they publish.

[pq]

@kevmoo: any updates?

[kevmoo]

@natebosch is driving things here AFAIK

[natebosch]

We are currently evaluating and preparing for a couple breaking changes which needs to happen before the null safety migration can be published. Those are:

• added optional body to delete #439
• Tighten argument types to Uri #507
• Design an API to support aborting requests #424

#424 is looking like it may need more design work before we can move forward with it, so it's plausible that we'll only block on adding a timeout: argument, and save the remaining work for a later version.

All of these are breaking changes for only a very small subset of consuming packages. Blocking the publish on these changes is mainly a function to reduce churn from multiple major version bumps, and to avoid blocking those changes until after the null safety release goes stable.

We are aware of the urgency for this migration and it's a high priority.

[ryanheise]

@natebosch As a suggestion, why not plan out the version numbers in advance, and "reserve" a major version number for the breaking release when it's ready, but publish a null safety prelease now using a major version above that?

I believe this is the approach taken by rxdart who jumped from rxdart 0.24.1 up to rxdart 0.26.0-nullsafety.0 while reserving 0.25.0 for a stable release of planned breaking changes.

[natebosch]

why not plan out the version numbers in advance, and "reserve" a major version number for the breaking release when it's ready, but publish a null safety prelease now using a major version above that?

Publishing with an unnecessarily high version number means that a breakage would flip-flop and make it impossible to use a range constraint.

You could be compatible with 0.12.x (today's version), and compatible with 2.0.0-nullsafety (the major version past what will are reserving), but you can't express that in the pubspec. We want to use ranges as much as possible as we are rolling out these packages to reduce the impact on pub solves. A range of >=0.12.0 <2.0.0 is what we'll use for most packages that aren't broken by changes we are making unrelated to null safety (most uses of the package aren't impacted). If we expect other breaking changes in 1.0.0 that aren't in 2.0.0-nullsafety then it would not be safe to use a range of >=0.12.0 <3.0.0.

[ryanheise]

You could be compatible with 0.12.x (today's version), and compatible with 2.0.0-nullsafety (the major version past what will are reserving), but you can't express that in the pubspec.

Only temporarily until 1.0.0 is released (after assessing its eventual compatibility). So it seems to me that:

• during that temporary period, this wouldn't negatively affect any existing version constraints, but it would unblock other package developers.
• after that temporary period (when 1.0.0 is released), other package developers could assess the 1.0.0 release for compatibility and then if applicable, relax their dependency version constraint to >=0.12.0 <3.0.0.

[ryanheise]

One other point concerning the various breaking APIs being introduced is that you could use the experimental annotation which would allow later changes without a version bump, "during" this transition period. That will buy you some time to refine things without blocking others.

I know it would be ideal to wait for the perfect API before releasing, but it is worth standing back and noticing that many package developers have come to the collective conclusion that they had better get any important breaking API changes in before the null-safety migration otherwise it could take a really long time to wait for the next major version bump where we can finally make those changes. If everyone takes the same attitude of trying to perfect their API before the transition, this is going to be a very painful and tiring migration. That is to say, even if the perfect http API is finished and published as soon as tomorrow, we need to learn from this and update the migration guide with new advice on how to not delay the process. I want it to be over quickly.

It is also worth considering that those who migrated their packages earlier may have it worse off because now the development of their package may be blocked until everyone else has caught up and the null safety branch can actually be used.

[renefloor]

I don't support create a 2.0.0-nullsafe version for when there are breaking changes in 1.0.0. This would also mean that if the breaking changes of 1.0.0 are also applied in 2.0.0 this breaks 2.0.0 and you would actually have to publish the nullsafe version as 3.0.0, as otherwise ^2.0.0-nullsafety.0 would potentially break packages.

However, I do wonder if we as community developers help speed up the development of these tickets, or that we are just waiting for internal discussions and development is not really the problem here.

If I'm correct the only one left is #424, it looks like a decision on how to go forward is made, but not everybody agrees on it yet. I'm happy to help with anything though.

[JohnGalt1717]

FYI, http is blocking build_runner which is blocking virtually any serious migration to null safety from most projects.

It's vital that this gets out at least in a pre-release form as soon as possible.

[natebosch]

http is blocking build_runner which is blocking virtually any serious migration to null safety from most projects.

build_runner is not going to be migrated in the near future, and does not block other migrations since it should not be imported.

We are aware that http is a very widely used dependency blocking many migrations and it is our highest priority external package to migrate and publish.

[kevmoo]

Your patience is greatly appreciated here. @natebosch and others are working VERY hard to make sure http is migrated correctly. As I'm sure many will understand, a mistake with such a popular package would cause many more delays – and a lot more pain.

[cyanglaz]

FYI, the image_picker plugin's NNBD migration is also blocked by this :) https://github.com/flutter/plugins/blob/master/packages/image_picker/image_picker_platform_interface/pubspec.yaml

[JohnGalt1717]

@natebosch If you add build_runner to dev_dependancies then it blocks everything else from being updated that depends on it (json_serializer, injectable, freezed etc.)

The build_runner team has committed to expanding the compatibility specs in their yaml to allow your null safety version when it comes out and all other packages thus allowing you to upgrade the entirety of the rest of your project before build_runner is updated.

Hence why I made the comment. There is a specific plan to make this work but it depends on http being updated to null safety or doing the same as build_runner.

Here's their issue: dart-lang/build#2920 (comment)

[natebosch]

If you add build_runner to dev_dependancies then it blocks everything else from being updated that depends on it (json_serializer, injectable, freezed etc.)

It is expected that during ongoing migration work you may need to use dependency_overrides to pick up the null safety migrated versions of some packages.

The build_runner team has committed to expanding the compatibility specs in their yaml to allow your null safety version when it comes out and all other packages thus allowing you to upgrade the entirety of the rest of your project before build_runner is updated.

I'm on the build_runner team. We will be publishing versions with expanded constraints on a best-effort basis to make things easier as packages are published. That dependency will not be migrated soon, and it does not block migrations. The null safe output from generators like json_serializable and injectable can be built with a non-migrated build_runner. And those packages should all be compatible with build_runner. In edge cases some dependency_overrides may be necessary.

To reiterate. No migration work is blocked by this package being unpublished. What is blocked is publishing other migrated packages that depend on this. I am fully aware of the pain caused by dependency overrides and publishing this package remains a high priority. The urgency is based on being able to publish other packages, not on being able to use the migrate tool and make the code changes which is already possible.

To make progress on a migration put the following in your pubspec:

dependency_overrides:
  http:
    git: git://github.com/dart-lang/http.git

You can follow this issue to know when you will be able to remove the override and be able to publish. As other breaking changes are made within this package, you may have to make small adjustments to your usage. I don't expect any further breaking changes that impact the majority of consumers between now and the null safety release. There may still be minor breaking changes that effect classes which extends http.BaseClient.

[natebosch]

Published https://pub.dev/packages/http/versions/0.13.0-nullsafety.0

We hit some more uncertainty around implementing timeouts so we're gonna hold off on that until we can work on a design alongside general request aborting.