Skip to content

Remove note about a fetch handler being required alongside DOs - #5185

Merged
a-robinson merged 1 commit into
cloudflare:productionfrom
a-robinson:fetch-handler
Jul 18, 2022
Merged

Remove note about a fetch handler being required alongside DOs#5185
a-robinson merged 1 commit into
cloudflare:productionfrom
a-robinson:fetch-handler

Conversation

@a-robinson

Copy link
Copy Markdown
Member

Because we're removing that requirement on script upload. It's still
often a good idea to bundle a fetch handler with a DO class, but will no
longer be required.

Because we're removing that requirement on script upload. It's still
often a good idea to bundle a fetch handler with a DO class, but will no
longer be required.
@a-robinson
a-robinson requested review from koeninger and xortive July 18, 2022 16:49
@github-actions
github-actions Bot requested a review from deadlypants1973 July 18, 2022 16:49
@a-robinson

Copy link
Copy Markdown
Member Author

I've confirmed this behavior is live.

@a-robinson
a-robinson merged commit f630dc6 into cloudflare:production Jul 18, 2022
taylorlee added a commit to cloudflare/workers-sdk that referenced this pull request Sep 5, 2026
Fixes #15309.

The legacy heuristic of assuming anything without a default export is
going more harm than good. It also seems like it must have regressed at
some point, because it used to be possible to have DO-class-only
Workers a [few years ago](cloudflare/cloudflare-docs#5185),
even though trying that now would fail by detecting SW syntax.

After looking at a bunch of options and various forms of required
back-compat, I think the best path forward is to resolve the ambigious
case in favor of modules workers.

Current heuristic:
* default export -> module worker
* otherwise -> service worker

New heuristic:
* no exports -> service worker
* default export -> module worker
* ambigious exports:
    - recognized global addEventListener reference -> service worker
    - otherwise -> module worker

This does that the most tricky dynamic constructions of SW can be
falsely interpreted as module workers if they have some named exports. I
think that's acceptable for a 2 reasons:
1. it is less harmful than misclassifying MW as SW
2. many of the most dynamic constructions (of either MW or SW) can't
   actually be deployed in practice (due to preexisting validator limitations),
   so the real breakage is minimal.

Alternatives considered: export-only heuristics, source regexes,
entrypoint-specific AST matching, an additional parser, and full dependency
bundling. These were avoided due to compatibility risks, false positives,
added complexity, or resolution overhead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants