Remove entryPoint if not required

[beaufortfrancois]

See gpuweb/gpuweb#4387

⚠️ Do not merge this PR until Chrome 121 reaches stable channel.

[Kangz]

FYI @jimblandy @mwyrzykowski this will simplify samples a bit but will require entryPoint name defaulting.

[kainino0x]

Converting to draft to make the PR harder to accidentally merge.

[beaufortfrancois]

We can now merge it as Chrome 121 is stable.

[greggman]

ps: Firefox still requires entryPoint as of nightly 124.0a1 (2024-01-25) (64-bit)

@kdashg @jimblandy

[kdashg]

Just a sec!

[jimblandy]

So, we agree this is a sweet readability hack, and would like to see it deployed in the examples - but since it will break Firefox, we would like to wait to merge this PR until gfx-rs/wgpu#5145 is closed.

waiting for firefox to update

[jimblandy]

Note that we need both gfx-rs/wgpu#5145 (the wgpu-side work) and Bugzilla Bug 1877488 (the Firefox bindings work) fixed before Firefox will be able to handle omitted entry point names. @ErichDonGubler is actively working on these.

[beaufortfrancois]

Firefox Nightly now handles omitted entry point names (I've checked locally).
Since Safari Tech Preview and Chrome also handle them properly, I believe we can now merge this PR.

Note that I've just rebased it due to merging conflicts.

[ErichDonGubler]

As the person who worked on this support in Firefox, I'm excited to see this land. 😁

[beaufortfrancois]

I've had to update the PR again. Please review and merge ;)

[ben-clayton]

Are the changes to package-lock.json intentional?

[beaufortfrancois]

Yes. They are due to me running npm i because of iframe changes.

[ben-clayton]

But it doesn't look like any of the code changes should affect the packages? Is it that main has a stale package-lock.json? If so, can we do that as a separate PR?

[beaufortfrancois]

You're right. I'll revert package-lock.json changes then to not pollute this PR.

[beaufortfrancois]

Done

[beaufortfrancois]

@kainino0x Can you merge?

[greggman]

I'll merge