Remove package:js dependency in build_web_compilers

[simolus3]

package:js has been deprecated in favor of the new dart:js_interop library (and package:web). This migrates a package:js import in build_web_compilers used in a helper program to implement StackTrace.toString for DDC apps.

I've replaced the package:js import with the new interop library, removed the dependency and ran dart run build_runner build in the build_web_compilers directory.

[github-actions]

PR Health

[simolus3]

I'll try to unpin the analyzer dependency in build_modules, IIRC json_serializable has been patched to work with that version. That should fix the drift community tests.

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:build	2.4.3-wip	WIP (no publish necessary)
package:build_config	1.1.3-wip	WIP (no publish necessary)
package:build_daemon	4.0.5-wip	WIP (no publish necessary)
package:build_modules	5.0.13	already published at pub.dev
package:build_resolvers	2.4.5-wip	WIP (no publish necessary)
package:build_runner	2.4.16-wip	WIP (no publish necessary)
package:build_runner_core	9.0.0-wip	WIP (no publish necessary)
package:build_test	3.0.0-wip	WIP (no publish necessary)
package:build_web_compilers	4.1.5	ready to publish	build_web_compilers-v4.1.5
package:scratch_space	1.0.3-wip	WIP (no publish necessary)

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[davidmorgan]

@simolus3 the "community" tests are still failing but I think that's unrelated to this PR? If so I can approve+merge this.

There have been a lot of changes to build_test, I am anyway expecting that while generators will keep working with the next release there is some work needed to get e2e tests working again. (bulid_test will have a breaking release).

[simolus3]

If so I can approve+merge this.

Yes, the community tests aren't doing anything with these assets so I think that failure is unrelated.

Drift tests work with the latest released packages so there might be an issue in other unreleased changes - I'll try to reproduce this locally.

[simolus3]

@davidmorgan I don't think the failure is drift's fault, it really looks like a regression, probably in build_runner_core.

The failing builders look like this:

[SEVERE] build_modules:module_library on test/integration_tests/regress_2166_test.g.g.dart (cached):

AssetNotFoundException: drift|test/integration_tests/regress_2166_test.g.g.dart
package:build_runner_core/src/generate/single_step_reader_writer.dart 314:7  SingleStepReaderWriter.readAsString
package:build_modules/src/module_library_builder.dart 34:7                   ModuleLibraryBuilder.build
package:build/src/generate/run_builder.dart 99:7                             runBuilder.buildForInput
dart:async/future.dart 528:21                                                Future.wait.<fn>
package:build/src/builder/logging.dart 39:11                                 scopeLogAsync.<fn>

Looking at the source in build_modules, the asset being read is buildStep.inputId. Considering the message (there's a duplicate .g.dart suffix on the asset id), it looks like a builder is running on an asset that doesn't exist!

It wouldn't surprise me that .g.g.dart is part of the asset graph (.dart source input -> .g.dart being generated by source_gen -> that matching source_gen again to possibly output .g.g.dart??). But since the file is not actually emitted, build_modules really shouldn't have a build step for it, so this looks like a regression in build_runner_core.

You should be able to reproduce this by following the steps in community.yml manually (cloning drift into client_tests/drift, manually patching the pubspec in client_tests/drift/drift to add path overrides for drift_dev and sqlparser, then running patch_build_dependencies and build_runner build). Let me know if there's anything else I could do to help.

[davidmorgan]

Filed #4006 for the community tests issue, I'll take a look. Thanks.

For this PR I'll go ahead and merge+release. Thanks for that, also :)