Skip to content

add importable exports to cloudflare module#5516

Merged
anonrig merged 2 commits intomainfrom
yagiz/add-importable-exports
Nov 18, 2025
Merged

add importable exports to cloudflare module#5516
anonrig merged 2 commits intomainfrom
yagiz/add-importable-exports

Conversation

@anonrig
Copy link
Copy Markdown
Member

@anonrig anonrig commented Nov 12, 2025

Adds ability to do the following:

import { exports } from 'cloudflare:workers'

@anonrig anonrig requested review from a team as code owners November 12, 2025 21:08
@danlapid danlapid requested a review from kentonv November 12, 2025 21:11
@github-actions
Copy link
Copy Markdown

github-actions bot commented Nov 12, 2025

The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉

@anonrig anonrig force-pushed the yagiz/add-importable-exports branch 2 times, most recently from 3034db4 to 10de35a Compare November 12, 2025 21:23
@codspeed-hq

This comment has been minimized.

@DaniFoldi
Copy link
Copy Markdown
Contributor

DaniFoldi commented Nov 12, 2025

Hi @anonrig,

I love this concept, and ctx.exports is pretty cool, however is this method of consuming it potentially going to get confused by build tools/etc if they are also using https://www.npmjs.com/package/cloudflare? Perhaps cloudflare:cloudflare or cloudflare:self would be more predictable?

Nevermind, looking at the code I see that the actual import would be from cloudflare:workers, which is fine

@jasnell
Copy link
Copy Markdown
Collaborator

jasnell commented Nov 13, 2025

Can you expand on the use case a bit in the PR description to provide some context for what/why this is needed.

@anonrig
Copy link
Copy Markdown
Member Author

anonrig commented Nov 13, 2025

Can you expand on the use case a bit in the PR description to provide some context for what/why this is needed.

cc @threepointone

@kentonv
Copy link
Copy Markdown
Member

kentonv commented Nov 13, 2025

Can you expand on the use case a bit in the PR description to provide some context for what/why this is needed.

It's exactly the same as the use case for importable env. ctx.exports contains automatically-configured bindings... the way they are used is very similar to regular bindings.

@anonrig anonrig force-pushed the yagiz/add-importable-exports branch from 10de35a to 11dd8cd Compare November 13, 2025 17:30
@anonrig anonrig force-pushed the yagiz/add-importable-exports branch from 11dd8cd to 16fc75f Compare November 13, 2025 17:34
@anonrig anonrig requested a review from jasnell November 13, 2025 17:34
@anonrig anonrig requested a review from jasnell November 14, 2025 14:46
@anonrig anonrig force-pushed the yagiz/add-importable-exports branch from 0e61fd0 to c712723 Compare November 17, 2025 16:26
@anonrig anonrig requested a review from jasnell November 17, 2025 16:26
Co-authored-by: Pete Bacon Darwin <pete@bacondarwin.com>
@anonrig anonrig merged commit e23e46d into main Nov 18, 2025
31 of 34 checks passed
@anonrig anonrig deleted the yagiz/add-importable-exports branch November 18, 2025 15:23
impl->ctxExports = lock.v8Ref(ctxExports.As<v8::Value>());

if (!FeatureFlags::get(js).getDisableImportableEnv()) {
v8::Local<v8::Object> exportsObj = ns;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is supposed to link up to ctxExports, not to ns.

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.

5 participants