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

2.7.0 breaks Astro visual editing support #2150

Open
DavithkbY opened this issue Nov 13, 2024 · 18 comments
Open

2.7.0 breaks Astro visual editing support #2150

DavithkbY opened this issue Nov 13, 2024 · 18 comments

Comments

@DavithkbY
Copy link

The visual editor is broken in Astro with 2.7.0 and also 2.6.0:
image

@maazuddindenovers
Copy link

Facing the similar kind of issue.

image

After doing some research i found some solution related lodash package, so in vite config i added this in astro.config file

image

This solved my issue my visual-editing-component (overlays) worked fine but in studio i faced different issue which is
when i updated any field inside presentation tool and do some changes, it worked fine but after some seconds in console i saw these warnings

image

Then in presentation tool, it shows this

image

@DavithkbY
Copy link
Author

@maazuddindenovers I have the exact same problem with the visual editor where the first edit just works and shows. When making a second edit, it just crashes. This is not only on 2.7.0 version but also on older versions like 2.4.1 etc...

@maazuddindenovers
Copy link

@DavithkbY , Yeah, i have also tried multiple older version, but there are still some kind of errors, Not sure I think these issues are causing with some dependents/dependencies and someone also look into this package also is this related to this package @sanity/astro or not.

@rdunk
Copy link
Member

rdunk commented Nov 15, 2024

I think this issue is likely related to @sanity/visual-editing. If you're able to bump that dependency to its latest version and let me know if things improve that would be much appreciated!

@DavithkbY
Copy link
Author

Hi @rdunk do you mean 2.7.1? With version 2.7.1 it's still broken:
image

My package.json:

"overrides": { "vite": { "rollup": "npm:@rollup/wasm-node" } }, "dependencies": { "@astro-community/astro-embed-youtube": "^0.5.6", "@astrojs/check": "^0.9.4", "@astrojs/netlify": "^5.5.4", "@astrojs/react": "^3.6.2", "@astrojs/rss": "^4.0.9", "@astrojs/sitemap": "^3.2.1", "@astrojs/tailwind": "^5.1.2", "@inlang/paraglide-astro": "^0.2.2", "@portabletext/react": "^3.1.0", "@portabletext/to-html": "^2.0.13", "@sanity/astro": "^3.1.6", "@sanity/cli": "^3.64.1", "@sanity/client": "^6.22.2", "@sanity/image-url": "^1.1.0", "@sanity/visual-editing": "^2.7.1", "@types/node": "^22.7.5", "@types/react": "^18.3.11", "@types/react-dom": "^18.3.0", "astro": "^4.16.13", "astro-embed": "^0.9.0", "astro-portabletext": "^0.10.1", "build": "^0.1.4", "dotenv": "^16.4.5", "feed": "^4.2.2", "fs-extra": "^11.2.0", "groq": "^3.64.1", "npm": "^10.9.0", "react": "^18.3.1", "react-dom": "^18.3.1", "rss": "^1.2.2", "run": "^1.5.0", "sanity": "^3.64.1", "shelljs": "^0.8.5", "tailwindcss": "^3.4.13", "tailwindcss-animated": "^1.1.2", "typescript": "^5.6.3", "uuid": "^10.0.0", "xml2js": "^0.6.2" }, "devDependencies": { "@inlang/paraglide-js": "1.11.3", "@sanity/export": "^3.41.0", "@tailwindcss/typography": "^0.5.15", "@types/fs-extra": "^11.0.4", "@types/rss": "^0.0.32", "@types/xml2js": "^0.4.14", "prettier": "^3.3.3", "prettier-plugin-astro": "^0.14.1", "prettier-plugin-tailwindcss": "^0.6.8", "tsx": "^4.19.1", "vite": "^5.4.11" }, "optionalDependencies": { "@rollup/rollup-linux-x64-gnu": "4.9.5" }

@DavithkbY
Copy link
Author

@rdunk I tried it again and it does seem fixed now with 2.7.1 amazing!

@rdunk
Copy link
Member

rdunk commented Nov 15, 2024

@DavithkbY Awesome! Glad to hear it and thanks for reporting.

@DavithkbY
Copy link
Author

@rdunk it randomly stopped working locally again. Nothing changes in the codebase literally 0 lines of code very weird.
It does work on the deployed live version but not local.
This error again:
image

en:4942 [astro-island] Error hydrating /node_modules/@sanity/astro/dist/visual-editing/visual-editing-component.tsx SyntaxError: The requested module '/node_modules/lodash/groupBy.js?v=ad36607e' does not provide an export named 'default'

@narration-sd
Copy link

narration-sd commented Nov 16, 2024

Just possibly another clue turns up.

  • I updated the 2.7.1 version on a test project, my blog addition to the base sanity-astro
  • it seems to work fine in dev
  • I got it going on Vercel, after much faffing as I'd forgotten best ways to get a monorepo set up there
  • but in addition the the monorepo config, in the end I had to align versions of sanity between portions of it, and then got errors for mismatched versions on other packages. So I cut the test repo down just to packages/sanity-astro, and apps/blog, ran ncu -u on each folder including the root, then remove all node_modules and pnpm-lock.yaml, then installed. I also had to update to tasks in the turbo.json since I use that to get the monorepo to build at this point. After all this, then a git commit-push let Vercel build with it, which succeeded.

Now. I tried this out. App -- fine. Studio on /admin -- looked fine at first. But, it failed to Live Edit actually, and after a while gave the prompt you've seen that it couldn't connect, which is studio to app.

In the console.log, this is logged, along eventually with the usual heartbeat no response.

But: there is something else, seemingly taking a while to show up: an Uncaught Error: path is required....and this having to do with ResolveEditInfo, which I seem to find inside the visual-editing package code.

This looks like a bit of a hot clue, and you can see it all on the screenshot I'm attaching. Hope it helps. Once again, this occurs on Vercel, but not on dev, and with the environmental config look like it is correct. The console indication is something missing, not mis-set....

The repo for this, if useful, is https://github.com/narration-sd/sanity-astro/tree/narration-sd/added-blog-example-vercel

Screenshot 2024-11-15 205801

@maazuddindenovers
Copy link

@DavithkbY I was facing this issue, so i looked into it

en:4942 [astro-island] Error hydrating /node_modules/@sanity/astro/dist/visual-editing/visual-editing-component.tsx SyntaxError: The requested module '/node_modules/lodash/groupBy.js?v=ad36607e' does not provide an export named 'default'

I found that in nodemoules at this path node_modules\@sanity\mutate\dist\_unstable_machine.browser.js groupby is being used as ES module

image

but in lodash package node_modules\lodash\groupBy.js, it is using the CommonJS

image

So i found out that i can use the "lodash-es" for ES module so i installed and then configured vite in astro config

  vite: {   
    resolve: {
      alias: {
        lodash : 'lodash-es'
      }
    },
  },

but not sure, it is the right solution or not but @rdunk can tell more on this.

@narration-sd
Copy link

narration-sd commented Nov 17, 2024

@maazuddindenovers Maaz, I'm suspecting your lodash situation has been something to do with your app, rather than this sanity-astro issue. I see no such errors, but put in your alias to lodash-es, which seems accepted (as long as I add it to pnpm), but makes no changes I can see to the no-visual-editing problem -- but was a good thought :)

I pushed further on what appears here, by creating a Netlify-compatible config, and deploying on Netlify.

This fails to visual edit also, just as we've been seeing, and has the same logging of 'uncaught Error: path is required'. The image is this time is from Chrome latest, instead of Firefox latest, but the result is the same, as you can see below.

  • the errors don't appear right away on shift-loading, but when you hover the mouse over the web page frame
  • this fits that they are coming from visual-editing's helper running in the page, via the visual-edit import in sanity/astro package's visual-editing-component.tsx, as the stack traces suggest.
  • It's somehow a little difficult to unwind how that calls 'resolveEditInfo' to fail, but presumably you have a dev setup where you can run all with observation.
  • I looked through source, where the error seems to arise, and 'path' appears to be about missing a 'baseUrl' in the internal naming, which looks that it's spread from config. But the only configuration for baseUrl seems to be in multi-workspace studios, and it has never been needed before.
  • in case it might be something else, I even tried enriching the fetch-time config, but no help from that.

Ok. I have to leave it, hopefully with more clues. The Netlify version including trial steps today is here.

Screenshot 2024-11-16 152638

@narration-sd
Copy link

OK, I felt to hit this one more time late in evening -- and now can demo the bug locally rather than on deploy serverless, so it should be much easier to troubleshoot.

This is done by using the Astro Node adapter, which allows SSR locally after a normal build. And running that way shows the same error it appears precisely, as occurs deployed -- website pane can't connect, and the 'path is required' error shows in the console, with effectively the same stack trace, when you hover mouse over it, as before.

Here's the repo branch (and all of these have sample content in the apps/blog/content folder)

The requisite screenshot, back on Firefox this time. Other variations on using local serverless clis have been tried, none of which allowed this local error demonstration. A certain amount of LLM discussing was useful, helping along, and it finally suggested trying this Node approach, which does the trick..

Screenshot 2024-11-17 010054

@DavithkbY
Copy link
Author

@narration-sd I think you have a different problem. The solution of @maazuddindenovers by adding lodash-es does solve my problem. And I have no more errors.

@DavithkbY
Copy link
Author

Okay nevermind. Applying @maazuddindenovers his fix only fixes the issue on my local version. On Netlify I have the same 'path' error as @narration-sd

@narration-sd
Copy link

narration-sd commented Nov 18, 2024

@rdunk, I hope this is all clear enough by the end for you....

  • the problem solidly exists, preventing Visual Editing from working with sanity-astro in latest versions
  • @DavithkbY knows he's having it now as well
  • my last comment with screenshot shows it happening with a setup that can be built and run locally, because it uses the Node adapter -- repo with even a content package given there to make all straightforward for you to work with
  • we first have seen it on serverless deployments, Vercel, also Netscape, also proven further above.
  • Thanks your efforts! and now it's late here...

@maazuddindenovers
Copy link

maazuddindenovers commented Nov 19, 2024

@rdunk , The issue is mentioned/explained by @narration-sd using node adapter in local and on netlify, That is also replicating for me

@narration-sd
Copy link

narration-sd commented Nov 21, 2024

Ok, I have just verified that @sanity/[email protected] allowing Vercel and Netlify deployments to do Presentation operations again properly, as well as under the Node adapter on a local build. The work is based on @DavithkbY having brought up the new version as possible fix on our Slack discussion.

You can find my projects as before under my fork https://github.com/narration-sd/sanity-astro, where there are branches named for each of the deployment types, and including sample content that works with each.

The path to getting all three to work was complicated by some apparent configuration errors in the @sanity/sanity-astro repo.

  • in the package.json for packages/sanity-astro, there's a spurious extra definition for visual-editing, under peer dependencies. This should not be present at all, since the package under packages is where @sanity/visual-editing is actually used. Further, this peer dependency is not updated by ncu -u, which I use to assure contemporary packages are set when updating, as to the new 2.8.0.
  • then, there is what also looks like a bogus configuration in the root .npmrc file: auto-install-peers = true. This causes the errored peer dependency just mentioned to be used as well apparently as the direct dependency, and so there become two versions of @sanity/visual-editing present -- the old and the new. The incorrect older version gets used in building the in-monorepo package, and so whatever is in the old visual-editing continues to be used -- the broken 2.7.1 version in the present case.

I left these faults in my examples so they can be seen, but manually updated the peer dependency in order to create a working project on each branch, testing them on actual deploys, where they work normally now.

I'm not issuing @sanity/sanity-astro because the Sanity dev team would probably rather choose corrections themselves, as they appear to be a direct part of the problems worked on here.

@rdunk, let me know if you want something else, thanks. The extra problems I've detailed here occur for any project built in or added to the @sanity/sanity-astro monorepo.

@narration-sd
Copy link

narration-sd commented Nov 22, 2024

@rdunk Rupert, et al, I've produced an issue over the @sanity/astro problem and fix for success in applying 2.8.0.

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

4 participants