Using subdirectory on production build

[gitaarik]

I want to run my app in a subdirectory on my webserver, like https://mydomain.com/subdirectory/. It works when I use:

"buildOptions": {
    "baseUrl": "https://mydomain.com/subdirectory/"
}

But then my dev server breaks with the error message:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://mydomain.com/subdirectory/_dist_/index.js. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

How can I make this work so that I can develop locally and that it also works when I make a production build?

I also tried to make the paths in build/index.html relative, and this works, and would actually be my preferred solution, since then the app can be deployed inside any subdirectory and it will work everywhere because that is what relative paths do. But every time I create a new build, the build/index.html file is overwritten and I would need to make the manual changes again. Isn't there an option for Snowpack to make the paths in the build relative? That would be very handy.

[FredKSchott]

Oh interesting, yea our build command was designed to represent the final build, but recently we've released snowpack build --watch and are committed to supporting local dev via the build command as well. So we should definitely fix up something for you here.

There are a couple of ways we could solve this. We could skip the baseUrl when you use build --watch, since we assume that this is for local development. Or, we could support something like multiple configuration files, so that you can set one build config for development and another for production.

Actually, as I type that, I realize that you could do that now! Our CLI has the --config option to specify which config file to load, so you could create two config files and use one for development & one for prod builds. Using npm, this would be represented as:

"scripts": {
  "build:dev": "snowpack build --watch --config snowpack.dev.config.js",
  "build:prod": "snowpack build --watch --config snowpack.prod.config.js",
  ...
}

[FredKSchott]

We do ignore baseUrl in the dev server (when you run snowpack dev)

[gitaarik]

When I set the buildOptions.baseUrl in the snowpack.config.json, my devserver breaks with this error message:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://mydomain.com/subdirectory/_dist_/index.js. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

[FredKSchott]

Oh, do you use PUBLIC_URL in your HTML file? I think I see a bug for that

[FredKSchott]

Fix here: #957

[gitaarik]

Nice, thanks!

[sebastienbarre]

I was asking myself the same question tonight, since I have to set buildOptions.baseUrl on my production server to a value different than my development machine.

I was wondering if @FredKSchott could chime in on my solution?

What I'm doing is leveraging @snowpack/plugin-dotenv so that I can simply set a variable in the .env.production.local file on the production server, a file that is obviously not committed to the repo.

Here is part of my snowpack.config.js:

const path = require('path')
require('@snowpack/plugin-dotenv')();

module.exports = {
  mount: {
    public: '/',
    src: '/_dist_',
  },
  plugins: [
    '@snowpack/plugin-react-refresh',
    '@snowpack/plugin-dotenv',
    ['@snowpack/plugin-webpack', {
      sourceMap: false
    }]
  ],
  buildOptions: {
    sourceMaps: false,
    baseUrl: process.env.SNOWPACK_PUBLIC_BASE_URL || '/',
    clean: true
  }
};

The trick here is baseUrl: process.env.SNOWPACK_PUBLIC_BASE_URL || '/',

And the .env.production.local on my production server:

SNOWPACK_PUBLIC_BASE_URL='/app/'

Does that make sense?

I wish I could have used something like PUBLIC_URL in snowpack.config.js, but it is set later, based on buildOptions.baseUrl, not the other way around.

Note that i'm usingSNOWPACK_PUBLIC_BASE_URL here, so that it is also available in my source, and I can inject it as the basename property of React Router:

<BrowserRouter basename={import.meta.env.SNOWPACK_PUBLIC_BASE_URL || '/'}>
  ...
</BrowserRouter>

You will want to update your public/index.html as well to fix the path to the favicons (<link rel="icon" href="%PUBLIC_URL%/favicon.ico" />), BUT do not update the path in <script type="module" src="/_dist_/index.js"></script> if you are building with @snowpack/plugin-webpack or it will fail, contrary to the Snowpack example in /test/build/base-url/public/index.html, which only works if you are building with snowpack itself.

Fred? Is it OK to rely on require('@snowpack/plugin-dotenv')();'s behavior in the future? I originally had tried require('dotenv').config() but that wasn't loading .env.local.

Thanks