pocketbase / js-sdk

PocketBase JavaScript SDK
https://www.npmjs.com/package/pocketbase
MIT License
2.06k stars 122 forks source link

404 when using a HTTPS baseUrl in Next.JS deployments (relative URLs being used instead of absolute) #275

Closed timkrins closed 8 months ago

timkrins commented 8 months ago

Hello,

Firstly, thanks @ganigeorgiev, this project is fantastic and you truly have the patience of a saint.

This is not a problem with this library, but just a heads up for anyone else experiencing a strange issue where relative URLs are being used in your PocketBase requests instead of absolute URLs, even when a fully-defined URL is given as the baseUrl.

I was using Next.JS 13.0.4 and PocketBase 0.20.3.

I have traced my issue to minification of the buildUrl function. See original https://github.com/pocketbase/js-sdk/blob/efb5b67a67347c529f51d9ac8a614e4210ac9868/src/Client.ts#L265

In the PocketBase dist files, the buildUrl function is transpiled with this as the result: (prettified for readability)

buildUrl(e) {
  let t = this.baseUrl;
  return (
    "undefined" == typeof window ||
      !window.location ||
      t.startsWith("https://") ||
      t.startsWith("http://") ||
      ((t = window.location.origin?.endsWith("/")
        ? window.location.origin.substring(0, window.location.origin.length - 1)
        : window.location.origin || ""),
      this.baseUrl.startsWith("/") ||
        ((t += window.location.pathname || "/"),
        (t += t.endsWith("/") ? "" : "/")),
      (t += this.baseUrl)),
    e &&
      ((t += t.endsWith("/") ? "" : "/"),
      (t += e.startsWith("/") ? e.substring(1) : e)),
    t
  );
}

But, after going through the build process with Next.JS and swc minification, it ends up like this:

buildUrl(e) {
  let t = this.baseUrl;
  return (
    "undefined" == typeof window ||
      !window.location ||
      t.startsWith("https://") ||
      t.startsWith("http://") ||
      ((t = window.location.origin?.endsWith("/")
        ? window.location.origin.substring(0, window.location.origin.length - 1)
        : window.location.origin || ""),
      this.baseUrl.startsWith("/") ||
        ((t += window.location.pathname || "/"),
        (t += t.endsWith("/") ? "" : "/")),
      (t += this.baseUrl)),
    e &&
      (t =
        (t.endsWith("/") ? "" : "/") +
        (e.startsWith("/") ? e.substring(1) : e)),
    t
  );
}

They are very similar, except for the last few lines. The minified result for some reason does not append to t (the minified url variable in the original source), but overwrites it, which means that the URL will never include the value originally in this.baseUrl.

Switching off minification in next.config.js fixed my issue. I am going to try and investigate exactly why, but I hope that others might find this useful.

timkrins commented 8 months ago

After a little fun doing a manual bisect... just my luck - a bug in Next.JS 13.0.4 - bumping to 13.0.5 produces correctly minified code... I now realise that this is actually a very old version of NextJS... It was fixed in the next v13.0.5-canary.3 release, likely by the newer swc_core version.

Lesson learned: bump dependencies before spending hours debugging!