[web_generator] Add support for passing files as globs

[nikeokoronkwo]

Fixes #425

This PR adds support to passing files as globs for both the IDL generator and the TS Declarations generator via Node's fs.globSync function.

[nikeokoronkwo]

The tests work on my machine successfully.
I'm assuming it is because of the node version used (because the error assumes globSync does not exist on fs).
Node version I tested with is v22 (LTS).

[srujzs]

Feel free to update the node version we use if you think that may be the issue (I believe that shouldn't result in any issues for package:web)

[nikeokoronkwo]

Feel free to update the node version we use if you think that may be the issue

Does mono_repo support set up actions? That way I can update it globally

[srujzs]

Hmm, this might be tougher than just updating package.json as it seems like the default GitHub actions still uses v20 for Node.

We could specify an action to setup-node with a newer version: https://github.com/actions/setup-node. It looks like mono_repo provides an on_completion option to add GitHub actions, but it's after all jobs are completed: https://pub.dev/packages/mono_repo#installation. That makes this a bit difficult because we want to setup the node version during each job (right after setting up actions). We could manually write each job in the on_completion but that defeats the point of mono_repo.yaml generating all the jobs we want.

@devoncarew Is there a better way to specify a newer Node version that I'm missing?

[devoncarew]

@devoncarew Is there a better way to specify a newer Node version that I'm missing?

I've largely moved away from using mono_repo; it adds a layer between the user and the actual CI definition that adds additional complexity, makes simple things harder, and doesn't really have additional value over just raw github actions.

I think it would be worth just adding a new workflow definitions per package in this repo (2?) and removing the mono_repo config info. Then things like specifying node versions and such should be straightforward. I can point you to some same workflows if helpful.

[srujzs]

I've largely moved away from using mono_repo; it adds a layer between the user and the actual CI definition that adds additional complexity, makes simple things harder, and doesn't really have additional value over just raw github actions.

I think it would be worth just adding a new workflow definitions per package in this repo (2?) and removing the mono_repo config info. Then things like specifying node versions and such should be straightforward. I can point you to some same workflows if helpful.

That makes sense. Do you have an example where you migrated away from mono_repo.yml? I'm tempted to keep dart.yml as the source of truth but it's quite messy and I wonder if there's cruft that can be removed.

For now, I believe @nikeokoronkwo will just glob things early so we don't need a new node version, but I'd like to move away from mono_repo.yml at some point as well.

[devoncarew]

That makes sense. Do you have an example where you migrated away from mono_repo.yml? I'm tempted to keep dart.yml as the source of truth but it's quite messy and I wonder if there's cruft that can be removed.

If you want to try switching, I authored #428. I believe it covers the same things that the two mono_repo config files were doing.

[nikeokoronkwo]

@srujzs Since #428 has landed, maybe I could bump the node version and proceed?

[srujzs]

Since #428 has landed, maybe I could bump the node version and proceed?

Yep, go for it! It looks like there's some failures around file names before we can land though.

[nikeokoronkwo]

Yeah, I can't quite get to why the builds are failing: the tests work on my system and they've been working up until now.