issues rolling into google3

[devoncarew]

We're seeing issues rolling into google3; as an example:

ERROR: [.../devtools_app/lib/src/shared/config_specific/import_export/_export_web.dart:8]
The library 'package:web/web.dart' doesn't export a member with the hidden name 'NodeGlue'. #undefined_hidden_name

import 'package:web/web.dart' hide NodeGlue;
                                   ^^^^^^^^

There may well be other issues. That one alone looks trickey as we'll need to either patch devtools in google3 or update the source of truth (flutter/devtools) w/ a not-yet-released version of package:web.

[srujzs]

1.1.1 is released and includes the deprecation: https://pub.dev/packages/web/versions/1.1.1. We should be able to update devtools with that constraint, right?

[srujzs]

Oh nevermind, I see what you mean - it was removed in 2.0.0.

[srujzs]

Do we need to roll this unreleased version into google3? I've only rolled in published or about-to-be-published versions into google3 in the past.

When we do plan on publishing 2.0.0, my roll plan would be to:

1. Check that it can be rolled into google3 % any fixes needed for third_party packages. If not, prep a hotfix.
2. Publish.
3. Update third_party packages.
4. Land the roll with any hotfixes into google3.

---

All this being said, we should roll 1.1.1 into google3 if you haven't prepped that already.

[devoncarew]

Do we need to roll this unreleased version into google3? I've only rolled in published or about-to-be-published versions into google3 in the past.

For most packages, we like to use the sdk and google3 rolls to vet changes (so, we roll before publishing).

Often you land a -wip version in the repo, or the release version w/o publishing.

All this being said, we should roll 1.1.1 into google3 if you haven't prepped that already.

I'm happy to prep a CL to do that.

[srujzs]

For most packages, we like to use the sdk and google3 rolls to vet changes (so, we roll before publishing).

Right, and that's the model we've been following when we can, but the third party packages are going to block that for 2.0.0. The best we might be able to do is a TGP using any changes we need for those third party packages.

Even without the removal of deprecations, updating the webref version can come across this issue as a good number of members will change.

I'm happy to prep a CL to do that.

Awesome, thanks Devon!

[devoncarew]

Right, and that's the model we've been following when we can

Ah, great; I wasn't aware.

but the third party packages are going to block that for 2.0.0. The best we might be able to do is a TGP using any changes we need for those third party packages.

sgtm; I think the purpose of rolling packages in before publish is to get advance notice of potential issues - a TGP run would do the same

[srujzs]

Ah, great; I wasn't aware.

To be fair, we clearly didn't follow it for 1.1.1 so we're not consistent. :p