Skip to content

Conversation

@matthewp
Copy link
Contributor

Changes

  • server.ts had the wrong format, should export a createExports, fixes that.
  • Duplicate JSON not used in the tests removed that caused warning

Testing

N/A

Docs

N/A

@changeset-bot
Copy link

changeset-bot bot commented Oct 22, 2025

⚠️ No Changeset found

Latest commit: 366d0e8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

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

@github-actions github-actions bot added the pkg: integration Related to any renderer integration (scope) label Oct 22, 2025
Copy link
Member

@florian-lefebvre florian-lefebvre left a comment

Choose a reason for hiding this comment

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

This was on purpose! createExports has to go away with the environment API

@ematipico
Copy link
Member

Yes, the change was intentional, but that doesn't mean createExports must be removed. We definitely cut down a lot of boilerplate; however, we introduced some breaking changes that need to be revisited.

With createExports, we could tell Astro which exports an adapter entrypoint can export. I don't know if this is still possible with the new implementation. Also, we have other places that rely on createExports, so we should definitely discuss it.

Regardless, I think we can accept the change, as long as the dev server of the fixture still works, which wasn't tested based on the description of the PR.

@florian-lefebvre
Copy link
Member

AFAIK createExports was only meant to pass manifest and args, not tell Astro which exports to keep. IMO that's the job of setAdapter({ exports: [...] }). But anyways I'm fine unblocking this if that allows moving forward as long as we get to discuss the API again before merging in next

@ascorbic
Copy link
Contributor

There would need to be exports for both in that case. The subpath export used as the entrypoint in wranger.jsonc needs to be an actual export, so if we keep createExports we'd also need an entrypoint that exports the actual object.

Copy link
Contributor

@ascorbic ascorbic left a comment

Choose a reason for hiding this comment

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

The either needs to export both, or we need a new entrypoint that exports the instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pkg: integration Related to any renderer integration (scope)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants