Pandorque
Pandorque

Reputation: 396

How to solve cache problems with npm workspaces and Vite in a monorepo

I'm using npm workspaces with Vite in a svelte project (using SvelteKit).

The architecture of my project looks like this :

- apps/
    - project-a/
        - package.json
        - vite.config.ts
- packages/
    - common-lib-a/
        - package.json
        - vite.config.ts
- package.json

My project-a has common-lib-a/ listed as a dependency in its package.json (with: "@namespace/common-lib-a": "^0.0.1"). Its vite.config.ts looks like this :

import { sveltekit } from '@sveltejs/kit/vite';
import dns from 'dns';
import Icons from 'unplugin-icons/vite';
import { defineConfig } from 'vite';
import { purgeCss } from 'vite-plugin-tailwind-purgecss';

const hash = Math.floor(Math.random() * 90000) + 10000;
dns.setDefaultResultOrder('verbatim');

export default defineConfig({
    plugins: [
        sveltekit(),
        purgeCss(),
        Icons({
            compiler: 'svelte'
        })
    ],
    resolve: {
        preserveSymlinks: true,
        dedupe: ['@namespace/common-lib-a']
    },
    optimizeDeps: {
        exclude: ['@namespace/common-lib-a']
    },
    build: {
        rollupOptions: {
            output: {
                entryFileNames: `[name]${hash}.js`,
                chunkFileNames: `[name]${hash}.js`,
                assetFileNames: `[name]${hash}.[ext]`
            }
        }
    }
});

In order to run project-a, I use a daemon that re-builds common-lib-a each time it detects changes in common-lib-a (with vide build), and I run project-a with vite dev. Here's the script part of the root package.json (build and dev commands are vite build/vite dev scripts):

"scripts": {
        "dev-project-a": "npm run build -w @namespace/common-lib-a && npm run dev -w @namespace/project-a",
        "watch-project": "nodemon -x 'npm run dev-project-a' -e svelte,js,ts,json --watch packages/common-lib-a/src",
    }

But still, it seems like Vite has a cache for common-lib-a, which results in changes not appearing unless I clear all of the cache in my browser for any modifications in common-lib-a, when running project-a.

Is there a way to solve this ?

Upvotes: 1

Views: 612

Answers (2)

ilharp
ilharp

Reputation: 57

Having the same issue when using yarn v4, and solved by clearing browser cache, as described in the Vite doc:

Caching

File System Cache

Vite caches the pre-bundled dependencies in node_modules/.vite. It determines whether it needs to re-run the pre-bundling step based on a few sources:

...

If for some reason you want to force Vite to re-bundle deps, you can either start the dev server with the --force command line option, or manually delete the node_modules/.vite cache directory.

Browser Cache

Resolved dependency requests are strongly cached with HTTP headers max-age=31536000,immutable to improve page reload performance during dev. Once cached, these requests will never hit the dev server again. They are auto invalidated by the appended version query if a different version is installed (as reflected in your package manager lockfile). If you want to debug your dependencies by making local edits, you can:

  1. Temporarily disable cache via the Network tab of your browser devtools;
  2. Restart Vite dev server with the --force flag to re-bundle the deps;
  3. Reload the page.

In my case I had to delete the browser data folder, restart browser, then rerun app using vite --force. Clearing site data and doing a hard refresh did not work for me.

Upvotes: 0

theo - dmno
theo - dmno

Reputation: 637

I suspect it is because you are linking by version when what you really want is to link to the local copy. This plus NPM does some funky stuff with caching locally that can be very annoying.

I'd suggest switching to pnpm which has much better monorepo/workspace handling. Then you can set the dependency to "@namespace/common-lib-a": "workspace:*" and it will use a symlink to the local copy of the lib within your workspace.

Alternatively, you can try in npm to link using the file path "@namespace/common-lib-a": "file:../../packages/common-lib-a" but from my experience with monorepos, if you switch over to pnpm you'll save yourself some headaches.

Upvotes: 0

Related Questions