publicPath in app.json::expo.web not honored anymore

[AlexGrafe]

The generated service worker <script> tag ...

<script>"serviceWorker"in navigator&&window.addEventListener("load",function(){navigator.serviceWorker.register("/service-worker.js")})</script>

uses /service-worker.js without prepending the publicPath registered in app.json under expo.web.publicPath.

[oxyii]

@AlexGrafe %PUBLIC_URL%service-worker.js instead /service-worker.js helps in my case but you are right, this is bug

[AlexGrafe]

I now found how also other paths don't use the publicPath anymore since expo-cli 3.1.2.

<link rel="manifest" href="/manifest.json">

[AlexGrafe]

Compare an older manifest.json with a newer one. My app name is simply clock.

Old (while correctly prepending the publicPath from app.json)

{
  "background_color": "#ffffff",
  "description": "A Neat Expo App",
  "dir": "auto",
  "display": "standalone",
  "lang": "en",
  "name": "Clock",
  "orientation": "portrait",
  "prefer_related_applications": true,
  "related_applications": [],
  "short_name": "Clock",
  "start_url": ".",
  "theme_color": "#4630EB",
  "icons": [
    {
      "src": "/clock/apple/icons/icon_180x180.621d690a0d6584e00bce45d25ead4983.png",
      "sizes": "180x180",
      "type": "image/png"
    },
    {
      "src": "/clock/apple/icons/icon_192x192.19de9c268927fc723eefffaf4f786495.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/clock/apple/icons/icon_512x512.07d1f26941f9f06abca5950411f31e31.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

New (where the same publicPath is not used anymore)

{
  "background_color": "#ffffff",
  "description": "A Neat Expo App",
  "dir": "auto",
  "display": "standalone",
  "lang": "en",
  "name": "Clock",
  "orientation": "portrait",
  "prefer_related_applications": true,
  "related_applications": [],
  "short_name": "Clock",
  "start_url": ".",
  "theme_color": "#4630EB",
  "icons": [
    {
      "src": "/apple/splash/icon_1125x2436.bdc68599ec49e3f8c4435ff9b0f2ca6a.png",
      "sizes": "1125x2436",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_1136x640.34e7ecc73694b2c55412d324a43c3547.png",
      "sizes": "1136x640",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_1242x2208.a85d08bd0eb61114d584ba1ae0e2f24e.png",
      "sizes": "1242x2208",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_1242x2688.fd17819069d51a0709eba695b3026d30.png",
      "sizes": "1242x2688",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_1334x750.5d62d7f62752944e78cbe0ec6ad28cce.png",
      "sizes": "1334x750",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_1792x828.c3bb3089f85ffee0887b4d75b93b0600.png",
      "sizes": "1792x828",
      "type": "image/png"
    },
    {
      "src": "/apple/icons/icon_180x180.621d690a0d6584e00bce45d25ead4983.png",
      "sizes": "180x180",
      "type": "image/png"
    },
    {
      "src": "/apple/icons/icon_192x192.19de9c268927fc723eefffaf4f786495.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_2208x1242.f08d861e760324cd76c0413f89330af1.png",
      "sizes": "2208x1242",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_2436x1125.d0e56c90c6ad3ef539b5afdcc60f18a1.png",
      "sizes": "2436x1125",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_2688x1242.e1f400f8c2815c0592be799095dd15ca.png",
      "sizes": "2688x1242",
      "type": "image/png"
    },
    {
      "src": "/apple/icons/icon_512x512.07d1f26941f9f06abca5950411f31e31.png",
      "sizes": "512x512",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_640x1136.27e7b65287f491abf45f5990d983c8a2.png",
      "sizes": "640x1136",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_750x1334.205df5a73ddaed215e746dba48b1e7ba.png",
      "sizes": "750x1334",
      "type": "image/png"
    },
    {
      "src": "/apple/splash/icon_828x1792.233338976a2d6e9e4ce31b714826ea67.png",
      "sizes": "828x1792",
      "type": "image/png"
    }
  ]
}

[AlexGrafe]

@EvanBacon Could you please have a look if possible? I would imagine this impacts everyone who wants to host their expo web app in a subdirectory, e.g. https://mydomain.com/myapp instead of only https://mydomain.com.

[AlexGrafe]

@loq24 Check out this config file where apparently lots of the web options reside: https://github.com/expo/expo-cli/blob/master/packages/config/src/Config.ts

return {
    ...appManifest,
    name: appName,
    description,
    primaryColor,
    // Ensure these objects exist
    ios: {
      ...ios,
    },
    android: {
      ...android,
    },
    web: {
      ...webManifest,
      meta: {
        ...meta,
        apple: {
          ...apple,
          formatDetection: apple.formatDetection || 'telephone=no',
          mobileWebAppCapable: apple.mobileWebAppCapable || 'yes',
          touchFullscreen: apple.touchFullscreen || 'yes',
          barStyle,
        },
        viewport: webViewport,
      },
      build: {
        ...webBuild,
        output: buildOutputPath,
        rootId,
        publicPath,
      },
      dangerous: {
        ...webDangerous,
        noJavaScriptMessage,
      },
      scope,
      crossorigin,
      description,
      preferRelatedApplications,
      relatedApplications,
      startUrl,
      shortName,
      display,
      orientation,
      dir,
      barStyle,
      backgroundColor,
      themeColor: webThemeColor,
      lang: languageISOCode,
      name: webName,
    },
  };

[AlexGrafe]

In expo-cli::packages/webpack-config/src/webpack.config.unimodules.ts I see how something got removed that looks suspicious:

https://github.com/expo/expo-cli/commit/5845100909f6257c734c4f6f16b7e751d79de16e

[patrickjm]

Bump - I'm having the same issue. Unable to serve my expo web app on Gitlab Pages because they're hosted on a subdirectory.

[carlos-cubas]

Same here

[xeba84]

Hello Alex/Patrick,

I had the same problem (or I think so) publishing my App on IIS server. Looking a lot for a solution, I found one, at least for me.

First, I saw this: https://docs.expo.io/versions/v35.0.0/guides/customizing-webpack/ and then focused my search in this way. Finally, in this site: https://www.rrrhys.com/deploying-a-react-native-web-project-with-circleci I found this "magic lines"...

const createExpoWebpackConfigAsync = require("@expo/webpack-config");

module.exports = async function(env, argv) {
  const config = await createExpoWebpackConfigAsync(env, argv);
  // Customize the config before returning it.

  config.output.publicPath = "/app/";
  return config;
};

I hope this can help you.

[carlos-cubas]

from what i see this doesn't seem to work as expo-service-worker continues to be registered on root.

In my case I have the following configuration:

app1 -> example.com/ app2 -> example.com/app/

app2 appears to pick up the serviceworker registered for app1

Hello Alex/Patrick,

I had the same problem (or I think so) publishing my App on IIS server. Looking a lot for a solution, I found one, at least for me.

First, I saw this: https://docs.expo.io/versions/v35.0.0/guides/customizing-webpack/ and then focused my search in this way. Finally, in this site: https://www.rrrhys.com/deploying-a-react-native-web-project-with-circleci I found this "magic lines"...

const createExpoWebpackConfigAsync = require("@expo/webpack-config");

module.exports = async function(env, argv) {
  const config = await createExpoWebpackConfigAsync(env, argv);
  // Customize the config before returning it.

  config.output.publicPath = "/app/";
  return config;
};

I hope this can help you.

[EvanBacon]

This repo is deprecated. For future reference, please report bugs in the expo/expo-cli repo as I don't track deprecated repos. Currently the public path is resolved with the following method: https://github.com/expo/expo-cli/blob/69dc96d4790f0d35be145436c879f0c0e9f6964b/packages/webpack-config/src/env/paths.ts#L102-L129. It also seems that there are a couple issues being addressed here so I'll close it in favor of the most recently identified bug. https://github.com/expo/expo-cli/issues/1330