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

Build command fails when using react & vue components #153

Closed
ivoreis opened this issue Apr 30, 2021 · 5 comments
Closed

Build command fails when using react & vue components #153

ivoreis opened this issue Apr 30, 2021 · 5 comments

Comments

@ivoreis
Copy link

ivoreis commented Apr 30, 2021

When creating a new standalone Astro project the build command fails when vue or react components are imported/used

Looking at the code it seems that resolvePackageUrl is missing from the frontend options (https://github.com/snowpackjs/astro/blob/main/src/runtime.ts#L338-L346).

Can you help me understand why the frontend config doesn't needresolvePackageUrl in that scenario?

Info

[build] TypeError: resolvePackageUrl is not a function
    at acquireDynamicComponentImports (file:///.../node_modules/astro/lib/compiler/codegen/index.js:224:46)
    at codegen (file:///.../node_modules/astro/lib/compiler/codegen/index.js:583:34)
    at async convertAstroToJsx (file:///.../node_modules/astro/lib/compiler/index.js:32:12)
    at async transformFromSource (file:///.../node_modules/astro/lib/compiler/index.js:80:20)
    at async compileComponent (file:///.../node_modules/astro/lib/compiler/index.js:89:20)
    at async Object.load (/.../node_modules/astro/snowpack-plugin.cjs:24:22)
    at async runPipelineLoadStep (/.../node_modules/snowpack/lib/index.js:122225:32)
    at async Object.buildFile (/.../node_modules/snowpack/lib/index.js:122424:24)
    at async /.../node_modules/snowpack/lib/index.js:163081:37
    at async FileBuilder.build (/.../node_modules/snowpack/lib/index.js:163093:32)
    at async Object.loadUrl (/.../node_modules/snowpack/lib/index.js:182113:17)
    at async load (file:///.../node_modules/astro/lib/runtime.js:21:28)
    at async build (file:///.../node_modules/astro/lib/build.js:208:24)
    at async buildAndExit (file:///.../node_modules/astro/lib/cli.js:9:17) {
  __snowpackBuildDetails: { name: 'snowpack-astro', step: 'load' }
}

Versions

  • Astro@0.0.8
  • Snowpack@3.3.7
@natemoo-re
Copy link
Member

We are actually running two instances of Snowpack, so resolvePackageUrl is a way to link package resolution between the two instances. We essentially are passing it to the "backend" Snowpack to override its built-in resolvePackageUrl and use the same one as the "frontend" Snowpack.

I'm having a really hard time reproducing this one, though! Would you mind linking to a reproduction? Are you using :load, :idle, :visible, or just static?

@ivoreis
Copy link
Author

ivoreis commented May 1, 2021

I've added an example here. Any reference to React or Vue seems to throw this error.

Tour.astro contains Vue component that triggers this failure.

How to replicate:

  • npm i
  • npm run build

After that I see:

> astro build

[build] ! building pages...
[build] ✔ pages built.
[build] ! scanning pages...
[build] ✔ pages scanned.
[build] ! bundling client-side code.
[build] ✔ bundling complete.
[build] TypeError: resolvePackageUrl is not a function

Environment:

  • OS OSX 11.3
  • Node 14.16.1
  • NPM 6.14.12
  • Astro 0.0.9 (using the latest)

@natemoo-re
Copy link
Member

Thank you! Got it (not) working with that reproduction. I'm taking a look!

@kevinkassimo
Copy link
Contributor

kevinkassimo commented May 2, 2021

What seems to be happening is that during
https://github.com/snowpackjs/astro/blob/467820996f71b0c78f2000294cb6f3c0a8f3aca4/packages/astro/src/build.ts#L257-L262
one of the statics that got collected before (during processing for index.astro) and now request loading is Tour.astro.css. This triggers an attempt for Snowpack to look for Tour.astro component. As the requested resource is not a page (and thus searchForPage finds nothing), this load attempt is then triggered on frontendSnowpack.loadUrl in runtime.load, which, as it does not have it in inMemoryBuildCache of Snowpack (due to the previous load only on backendSnowpack that happens during index.astro construction), tries to go through each plugin to see if somehow it could be resolved, hitting Astro's snowpack plugin, trying to do codegen, notices Vue components, tries to load Vue, and then explodes due to no resolvePackageUrl for the frontendSnowpack.

I think the gist of it only happens for .astro components (not pages) if such component imports other peer React/Vue components. When an .astro page loads the .astro component it would work, since it must go through the rendering phase that is handled by the backendSnowpack. But the past resolution/rendered knowledge of backendSnowpack is not shared with frontendSnowpack; the supposedly produced css files like Tour.astro.css are also not written out to fs/known by frontendSnowpack (the only written-out fine is the direct outputs of .astro pages themselves, like the index.astro only outputs index.html). Thus if the .astro component causes a link to a static resource like Tour.astro.css, frontendWebpack would have no choice but to try generate it from scratch again, which, when React/Vue comes into play, explodes.

TBH I am also not super sure why the separation of the 2 snowpack instances is necessary. The main devil here is one Snowpack's past work and in-memory cache is not visible to the other.

natemoo-re pushed a commit that referenced this issue May 27, 2021
@natemoo-re
Copy link
Member

natemoo-re commented May 27, 2021

Thanks again for the investigation!

This has been fixed in #231 (to be released in astro@0.12.0) but I also just added a test for it in #263 in case there is ever a regression.

natemoo-re pushed a commit that referenced this issue May 27, 2021
natemoo-re pushed a commit that referenced this issue May 28, 2021
natemoo-re pushed a commit that referenced this issue May 28, 2021
natemoo-re pushed a commit that referenced this issue May 28, 2021
natemoo-re pushed a commit that referenced this issue May 28, 2021
natemoo-re added a commit that referenced this issue May 28, 2021
* fix(vscode): Markdown frontmatter should use TSX, not YAML

* test: add test for #153

* chore: bump deps

* chore: update to use @astrojs scope

* fix: Markdown parse error when only child is `{expression}`

* fix: update renderer edge cases

* fix: failing test

* fix: update renderer
ewatch pushed a commit that referenced this issue May 31, 2021
* fix(vscode): Markdown frontmatter should use TSX, not YAML

* test: add test for #153

* chore: bump deps

* chore: update to use @astrojs scope

* fix: Markdown parse error when only child is `{expression}`

* fix: update renderer edge cases

* fix: failing test

* fix: update renderer
SiriousHunter pushed a commit to SiriousHunter/astro that referenced this issue Feb 3, 2023
* fix(vscode): Markdown frontmatter should use TSX, not YAML

* test: add test for withastro#153

* chore: bump deps

* chore: update to use @astrojs scope

* fix: Markdown parse error when only child is `{expression}`

* fix: update renderer edge cases

* fix: failing test

* fix: update renderer
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

3 participants