Why are the integration tests skipped? Is it because other steps are failing?

Why are the integration tests skipped? Is it because other steps are failing?

Because they are currently disabled

@ditman FYI in case you aren't aware; maybe something you could look at while gardening? @bparrishMines That's assigned to you, are you actively working on it? We shouldn't leave whole tests suites disabled for extended periods if we can avoid it.

@stuartmorgan Yea im going to take a look into it now. I'll try to narrow down the specific test to skip, so we no longer skip all the integration tests.

@stuartmorgan is there an issue to track running integration tests compiled to WASM in CI?

We also likely DON'T want to publish this package depending on a pre-release package.

We also likely DON'T want to publish this package depending on a pre-release package.

Also definitely the case

@Rexios80 – can we help you here?

@kevmoo
The biggest blocker for me personally is flutter/flutter#151426 because without that I can't even run the integration tests compiled to WASM locally. It would be cool if we could get CI running WASM integration tests before we land this but that might not be feasible. I think we will have enough fixing up to do when we try running all package integration tests compiled to WASM so I don't want to add to it if I can avoid it.

I have a deployed WASM site with these changes here: https://beta.madadmaps.com. The performance upgrade from Skia is unreal! I think @ditman is busy with other things right now so that's probably what's actually blocking this from landing.

I'll prioritize this one over camera next, we definitely want to land google_maps: 8.0.0 (preferably with this tacked on: a14n/dart-google-maps#135) so we can move all of flutter/packages to web: 1.0.0 somewhat quickly. That way camera can land straight as a web: 1.0.0 package. WDYT @Rexios80?

(PS: As for testing in WASM, we definitely want to have it, but that's something that can be punted for another PR (for now). For now the "official" test is that the all_packages app builds. (/cc @kevmoo to confirm))

@ditman That all sounds good to me. We can push this through now if it helps with the web 1.0.0 transition and clean it up later if necessary.

@Rexios80 I had to request a small change from @a14n in the v8.0.0-dev.3 branch (to temporarily allow web: ">=0.5.1 <2.0.0"), but I think this is good enough to adopt the new web syntax (I know wasm is a little bit flaky yet, but this'll get there soon)

Updated my test app with the latest of this branch a14n's changes web: 1.0.0, and it looks pretty good!

• https://dit-maps-tests.web.app! (only JS, because multi-view is still not supported by skwasm)

The following packages had errors:
  packages/google_maps_flutter/google_maps_flutter:
    Missing CHANGELOG change

The example/web/index.html is not published anywhere, so this PR should be CHANGELOG exempt (as it is now).

@Rexios80 what do you think, should we ask a14n to publish 8.0.0 final? He doesn't like having some issues/warnings with innerHTML in his examples, but maybe I can contribute a fix for that similar to the tricks here or in gis_web?

The example/web/index.html is not published anywhere, so this PR should be CHANGELOG exempt (as it is now).

Does that pubspec have publish_to: none in it? Also this should be handled by #7192 if it lands before this.

what do you think, should we ask a14n to publish 8.0.0 final? He doesn't like having some issues/warnings with innerHTML in his examples, but maybe I can contribute a fix for that similar to the tricks here or in gis_web?

I say we wait until after flutter/flutter#152262 lands since it's so close. Then I should be able to run WASM integration tests locally and make sure there aren't any lingering issues. As for the warnings they're getting, they seem pretty open to changes so you can just contribute an encapsulation of the example into its own project. We should absolutely wait to land this until they release 8.0.0.

(#7162 would help too if we can push that through real quick)

The example/web/index.html is not published anywhere, so this PR should be CHANGELOG exempt (as it is now).

Does that pubspec have publish_to: none in it? Also this should be handled by #7192 if it lands before this.

It does, but the CHANGELOG requirement comes from the flutter/packages tooling, not pub's. Because things in the example are part of the pub.dev site, our tooling validates that if there's changes in "example", the package needs a CHANGELOG entry so it can be published.

Also this should be handled by #7192 if it lands before this.

Good point, I'll get that one landed so this PR can focus only in the google_maps_flutter_web package.

As for the warnings they're getting, they seem pretty open to changes so you can just contribute an encapsulation of the example into its own project. We should absolutely wait to land this until they release 8.0.0.

Yep, I'm going to wait to see what a14n prefers and send them that (it might be done by the time I wake up tomorrow, and if not, I'll try to catch them on discord :P)

(#7162 would help too if we can push that through real quick)

I think that #7162 is lacking the changes to spin up a bunch of new testers (like these), but with a new wasm_build_all_packages.yaml file or similar we can pass the --wasm flag to the build and drive scripts... Adding those is a little bit of a nuisance, they need to be landed in two stages (bringup:on and then off), and there's some "mandatory waiting" in between. I wouldn't say it can be done "quick" haha (or at least, not as quick as other things that we can do in this PR :P)

• OK, next steps for me is to help a14n with anything needed to publish google_maps: 8.0.0 with the web dependency bracketed. I'll try to catch them online tomorrow, see what they prefer.

I think that #7162 is lacking the changes to spin up a bunch of new testers (like these), but with a new wasm_build_all_packages.yaml file or similar we can pass the --wasm flag to the build and drive scripts... Adding those is a little bit of a nuisance, they need to be landed in two stages (bringup:on and then off), and there's some "mandatory waiting" in between. I wouldn't say it can be done "quick" haha (or at least, not as quick as other things that we can do in this PR :P)

I just want that to run tests locally. If there are more changes required to run in CI we can add them later.

I just want that to run tests locally. If there are more changes required to run in CI we can add them later.

Ah ok, I misunderstood and thought you wanted to enable them in CI as well. Then your change should be enough I think!

It does, but the CHANGELOG requirement comes from the flutter/packages tooling, not pub's. Because things in the example are part of the pub.dev site, our tooling validates that if there's changes in "example", the package needs a CHANGELOG entry so it can be published.

It's actually a little more complex than that; the tool knows which file actually shows up on pub.dev for a given package, and requires a version change when changing that file so that it can be published; the CHANGELOG check is so that if someone thinks about whether a change to the example that's not part of what should be displayed should get a mention in the CHANGELOG. Mostly that's because there are cases where we change example code explicitly to demonstrate something relevant (e.g., adding a missing permission to the project, or adjusting non-main-file example code). Often the answer is no and we override it, which is fine.