fix: consolidate getEntry() logic

[threepointone]

This consolidates some logic into getEntry(), namely including guessWorkerFormat() and custom builds. This simplifies the code for both dev and publish.

• Previously, the implementation of custom builds inside dev assumed it could be a long running process; however it's not (else consider that publish would never work).
• By running custom builds inside getEntry(), we can be certain that the entry point exists as we validate it and before we enter dev/publish, simplifying their internals
• We don't have to do periodic checks inside wrangler dev because it's now a one shot build (and always should have been)
• This expands test coverage a little for both dev and publish.
• The 'format' of a worker is intrinsic to its contents, so it makes sense to establish its value inside getEntry()
• This also means less async logic inside <Dev/>, which is always a good thing

[changeset-bot]

🦋 Changeset detected

Latest commit: 80cfc1a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
wrangler	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.developers.workers.dev/runs/1969624566/npm-package-wrangler-567

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.developers.workers.dev/prs/567/npm-package-wrangler-567

Or you can use npx with this latest build directly:

npx https://prerelease-registry.developers.workers.dev/runs/1969624566/npm-package-wrangler-567 dev path/to/script.js

[threepointone]

EDIT: I amended the PR to include guessWorkerFormat() inside getEntry()

In a subsequent PR, I might also extract guessWorkerFormat and include it into getEntry, for similar reasons as above

[petebacondarwin]

I have an idea I would like to consider for this refactoring. It may not work out for a number of reasons but I think it is worth looking into...

How about changing useCustomBuild() so that it only triggers a new useEsbuild() when the watched files change, rather than running the custom build itself.

Then rather than passing the entry object into the useEsbuild() hook, it would call getEntry() itself. This would have the benefit of also running the custom build as necessary.

Happy to jump on a call to talk around this.

[threepointone]

I considered including getEntry() inside bundle, but then it brought back a bunch of null checks that I wanted to avoid. I'd like to land this and revisit if it becomes an issue.