Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent handling of default imports (exports) in astro dev and astro build #5277

Closed
1 task
jsve opened this issue Nov 2, 2022 · 2 comments
Closed
1 task

Comments

@jsve
Copy link

jsve commented Nov 2, 2022

What version of astro are you using?

1.6.2

Are you using an SSR adapter? If so, which one?

None

What package manager are you using?

yarn

What operating system are you using?

Mac

Describe the Bug

When importing an external library (private npm package) i get inconsistencies between running dev and build.

When running dev imports work as expected, meaning I'm able to import both the default and named exports successfully. However, when running build I get the notorious:

Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.

Example

import Module from '@external/component';

In dev, importing Module gives me the expected React.FC:

[Function: Module] { propOne: '', propTwo: '' }

In build Module evaluates to:

{
  default: [Function: Module] { defaultProps: { propOne: '', propTwo: '' } }
}

Note that any named imports from the same package works both in dev and build:

import Module, { NamedModule } from '@external/component';

Where NamedModule works in both commands, but Module works only in dev.

Fixes

Based on #4692 I was able to noExternal the external libraries, which means that default imports work as expected.

I also tried adding logic in the code to set Module to Module.default after importing it as suggested here (#3174 (comment)).

Suggestion

Even if I was able to solve the issue as described in "Fixes", it seems weird that dev and build behave fundamentally differently for default imports. My suggestion is to align the configurations between these commands. If that's not possible, this should at least be documented in depth outside of the closed issues in the repo.

Link to Minimal Reproducible Example

Participation

  • I am willing to submit a pull request for this issue.
@bluwy
Copy link
Member

bluwy commented Nov 2, 2022

This is an inconsistency bug in Vite (vitejs/vite#9061), there's also a workaround like vitejs/vite#9061 (comment) you can try. Closing as it's an upstream issue.

@bluwy bluwy closed this as not planned Won't fix, can't repro, duplicate, stale Nov 2, 2022
@jsve
Copy link
Author

jsve commented Nov 2, 2022

NP! Please consider adding it to the documentation though. Don't want to scare people away from this awesome tool because of something like this!

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

No branches or pull requests

2 participants