Skip to content

Conversation

@NullVoxPopuli
Copy link
Contributor

@changeset-bot
Copy link

changeset-bot bot commented Mar 10, 2025

⚠️ No Changeset found

Latest commit: 955a8c9

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

@Windvis
Copy link

Windvis commented Mar 11, 2025

I think this is an actual bug in Embroider (vite), so this change would only work around it.

It's a valid exports config according to these docs: https://nodejs.org/api/packages.html#package-entry-points

@simonihmig
Copy link
Contributor

Thanks for bringing this up! I could get convinced to merge this as a workaround to unblock people, but I do agree this seems more like a bug in Embroider. The exports map was done like this very intentionally.

@evoactivity
Copy link

I've patched this workaround onto my project, but it would be nice if it wasn't needed.
What does a fix for this look like? I've read @Windvis' investigation but I don't really understand how verifying if the resulting target being importable would fix it, so if we find it's not importable, what should actually happen? Is embroider supposed to start guessing for the actual import path? If ./-private/* is set to null isn't vite supposed to fail when importing from that location?

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.

Production build (vite) fails with ember-headless-form

4 participants