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

If files.assets === 'public', Vite copies the directory's contents #587

Closed
Rich-Harris opened this issue Mar 21, 2021 · 6 comments · Fixed by #4214
Closed

If files.assets === 'public', Vite copies the directory's contents #587

Rich-Harris opened this issue Mar 21, 2021 · 6 comments · Fixed by #4214
Labels

Comments

@Rich-Harris
Copy link
Member

This potentially conflicts with our own static asset handling

@benmccann
Copy link
Member

Not sure if it's the same issue, but I saw @GrygrFlzr filed vitejs/vite#2587 about Vite's public directory as well

@jthegedus
Copy link
Contributor

jthegedus commented May 3, 2021

Hi, this issue is the cause for an annoying workflow/bug with the Firebase adapter.

The adapter reads the user's firebase.json configuration file to identify which dir contains static assets to push to the Firebase CDN, in Firebase this defaults to public and is almost never changed by the user. This results in the following process:

  • svelte-kit build outputs .svelte/output/client/_app/*
  • Firebase adapter then executes copy_static_files and copy_client_files which copies the static and .svelte/output/client/_app/* dir contents to public
  • on subsequent svelte-kit build executions Vite then copies public contents into .svelte/output/client/_app/*, then outputs the new build as well, resulting in .svelte/output/client/_app/* and .svelte/output/client/_app/_app/*. This then gets copied by the adapter copy_static_files and copy_client_files into public.
  • each re-run of svelte-kit build produces a further nested _app dir in .svelte/output/client/ resulting in increasingly large uploads to the CDN

Is it possible for my adapter to specifically disable this Vite config or should we disable it within SvelteKit, because it is causing a conflict for my use case?

@jthegedus
Copy link
Contributor

jthegedus commented May 6, 2021

The current workaround for the Firebase adapter is documentation to users to add

// package.json
"build": "npx rimraf <dir used in firebase.json:hosting.public> && svelte-kit build --verbose",

Again, the default value is public, but ideally this would be something these users didn't have to worry about.

@theodorejb
Copy link

theodorejb commented Nov 24, 2021

I am also running into this issue. Is there an official workaround or fix planned?

@theodorejb
Copy link

I was able to work around this issue by setting the following in svelte.config.js:

const config = {
    // ...
    kit: {
        // ...
        vite: {
            publicDir: false,
        },
    },
};

Would it make sense for SvelteKit to set publicDir to false by default to avoid the current unexpected behavior?

Rich-Harris added a commit that referenced this issue Mar 4, 2022
…#4214)

* prevent Vite from copying static assets if directory is called public - fixes #587

* add test
@bluepuma77
Copy link

bluepuma77 commented Mar 12, 2022

Shouldn't this be resolved in latest SvelteKit v1.0.0-next.295 from npm?

When I place static files in SvelteKit /static/public I get the following message:

files in the public directory are served at the root path.
Instead of /public/bootstrap/bootstrap.min.css, use /bootstrap/bootstrap.min.css.

I still have to manually set the vite setting and restart SvelteKit.

const config = {
  kit: {
    ...
    vite: {
      publicDir: false
    }
  }
};

Update: It seems I need to add it only for npm run dev, but with npm run build I get the message:

build_client: The value for kit.vite.publicDir specified in svelte.config.js has been ignored. This option is controlled by SvelteKit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants