vite-plugin added to @astrojs/netlify causes sanity-astro Studio to fail on Windows dev

[narration-sd]

I'm being a little thoughtful in reporting the issue here, but believe it's the correct place.

• Astro added the vite-plugin, for its features, to the @astrojs-netlify adapter@6.5.0
• as of this 6.5.0 version, @sanity/astro fails to run its integrated Studio under dev in Windows, reporting an EPERM as Vite attempts to add the Studio's modules
• turning off actual operation of vite-plugin by setting env NETLIFY_DEV=true does not remedy, nor does CHOKIDAR_USEPOLLING
• a workaround is to enumerate packages used by the studio and configure Vite to force-include all of them in the astro launch astro.config.mjs
• @astrojs/netlify seems to do little but add the complex vite-plugin; there's no Vite config apparent to cause the two-step include
• the two-step web page, then studio, vite deps construction fails with EPERM on windows because of known historic Windows file locking issues
• the EPERM doesn't happen on a Linux dev, and so 6.5.0+ operates transparently there
• under build and deploy to Netlify, the original application operates correctly, vite being differently involved.

That's a lot of material, but I believe covers necessary points.

It should be noted that this workaround is highly inappropriate for Sanity Astro users, as their culture is most often as agency 'designer'. Thus a fix should be found, no doubt for other Astro customers as welll. A means to defeat what vite-plugin is doing sufficiently to avoid the problem here would seem a good fit, covering at least all who don't engage with the extended Netlfiy features it offers. A simple Vite flag seems preferable to an environmental, and certailnly to the workaround's need for knowledgeable module listing with globs.

Here's the operational scenario, and temporary workaround.

Use these steps with the minimal repo cloned -- being sure to the N.B. at the botttom of this section!!!:

• a minimal implementation showing the fault is here, based on a micro astro skeleton.
  • run it using npm install, then npm run dev, then clicking the dev link to show a minimal html page
  • click the link on the page to attempt opening the Studio
  • you will get a persistent blank page, and after some extended seconds, the dev console will show an EPERM error from Vite attempting to substitute in an expanded node_modules/.vite/deps, but failing, as you can observe by looking there. That's the fault.

After conversation with Netlify support, a workaround was arrived at, force-including all modules used by the Studio via Vite config in the astro.config.mjs:

  integrations: [ ... ],
  vite: {
    optimizeDeps: {
      force: true,
      include: [
        'sanity/**/*',  // list further all that are includes in a real sanity.config.ts
      ],
    },
  },
  adapter: netlify()

This is sufficient for the minimal demo, and works when extended to include all modules used in a real site Studio's sanity.config.ts. Which is awkward, but does function for proving.

When you add the workaround config to the minimal tester, then clicking the Studio link will give a properly expected error that there is no projectId specified, as in this screenshot; and there will be no EPERM showing in the dev console.

When a fully configured Studio is tested, it simply operates correctly once the special Vite config has been added, demonstrating all complex visual editing etc. operations.

Screenshot of properly working minmal demo's expected error:

N.B. PLEASE BE VERY THOUGHTFUL HERE!!!

...if you have done the above, run and seen the EPERM fail, then added the 'workaround' to see the screenshot result which is proper operation for this minimal reproduction....

...then you must afterwards completely remove node_modules/.vite folder before testing in any way for the EPERM fail again. Otherwise Vite will see a fully constructed deps, and not exercise its double dep building which causes (on Windows) the fail....

Of course you must do this every time, in developing a fix.

[narration-sd]

...added a quite important N.B. to the procedure to reproduce the fault -- so that you can reproduce it again, after the first time...!!

I would also inform you that to the suggestion of your quite valued mail support discussions person Clarence A., I've added a similar issue to Vite itself, which you can find in their form here.

Hope that gets proper persons together from teams, with good understandng why it's motivated.

[narration-sd]

We have a reply already from the Vite team, which looks it might be quite helpful in pinpointing the areas of the vite-plugin which are involved in this issue.

I've noted back, there, keeping an eye on at least one possible way Vite itself might be further involved, so we'll have to see at more detailed work.

But this -- and their involvement -- looks quite helpful to see.

Best to your own eyes on,
Clive