formatRelative is failing in a production build about date-fns HOT 5 OPEN

You're welcome!

How did you retrieve that bundler information to debug?

I simply located the JS file generated by the bundler (in the dist directory if I remember correctly) and ran it through Prettier. Seems like there are better ways to analyze the bundle and generate un-minified code and source maps though:
https://docs.plasmo.com/framework/workflows/build

from date-fns.

Which version of date-fns are you using?

Are you getting the same error if you use the format function directly with the p token? ex: format(new Date(), 'p')

I think the longFormatters internal module might not get bundled in your production builds for some reason. If you can share a minimal reproduction of the issue in a Github repo that includes the build pipeline, I'll have a look.

from date-fns.

It errored on the latest, 3.2.0.

Full deps list:

  "dependencies": {
    "@plasmohq/messaging": "0.6.1",
    "@plasmohq/storage": "1.9.0",
    "@tanstack/react-query": "5.17.12",
    "date-fns": "3.2.0",
    "firebase": "10.7.1",
    "plasmo": "0.84.0",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-imask": "7.3.0",
    "react-verification-input": "^4.1.0",
    "tailwind-merge": "2.2.0"
  },
  "devDependencies": {
    "@ianvs/prettier-plugin-sort-imports": "4.1.1",
    "@types/chrome": "0.0.256",
    "@types/node": "20.11.3",
    "@types/react": "18.2.48",
    "@types/react-dom": "18.2.18",
    "autoprefixer": "10.4.16",
    "postcss": "8.4.33",
    "prettier": "3.2.2",
    "tailwindcss": "3.4.1",
    "typescript": "5.3.3"
  },

The error does indeed occur just with format(new Date(), 'p'), yes.

Reverting back to 3.1.0 fixes the issue.

I've tried this with vanilla react, and couldn't get it to break. We're developing a chrome extension, and using Plasmo to build, sample project here - https://github.com/seaders/date-fns-example . And, after dev'ing that, it seems like the error is occuring there with a production, or development build.

from date-fns.

Thanks for the additional details, especially the fact that 3.1.0 works properly.

It's very likely that this is a Plasmo and/or Parcel bundler bug, maybe you can report this or ask for support in the Plasmo community.

Here's what I found:

The key related change in date-fns 3.2.0 is that some imported modules in format are both used and re-exported in the same module. v3.1.0...v3.2.0#diff-7b1dbecd4320b0086a9c54676a8d78a90ab1e5b6155296091887aa19e47834f2R21-R24

imports:

re-export (the new line from 3.2.0):

and later down, actual internal usage:

Screenshot diff between how Plasmo bundles these specific modules with 3.1.0 (before the re-export) and current 3.2.0:

The bundler seems to think that the formatters/longFormatters imports can be safely excluded, which is obviously not the case. Perhaps this is happening because they are re-exported before being used in the module itself, and they are not re-imported from that location internally?

Workaround:

I managed to successfully trick the bundler by importing these functions in the app and referencing them. Seems to work in both dev and prod builds.

import { format, formatters, longFormatters } from "date-fns"

const FORCE_BUNDLE = [formatters, longFormatters]

export default function IndexPopup() {
  const date = format(new Date(), "p")

  return <div>Date: {date}</div>
}

Hope this helps in the short term, but ultimately I think this should be reported and more carefully investigated on the Plasmo side. Maybe @kossnocorp will have some additional insights, but things look fine on date-fns' end from my pov.

from date-fns.

Many many thanks for that response @fturmel adding forced bundle has resolved it for me, but I have also raised the issue with the plasmo guys too.

Quick question on that plasmo screenshot you posted. How did you retrieve that bundler information to debug? I'd like to know, to have maybe been able to figure this myself, but also, funnily enough, to try force this situation for another part of another library. Totally unrelated to date-fns, but we've just hit an issue where our extension is being rejected from the (google) chrome web store for "remote code inclusion" because a (google) firebase library is including a dynamic load of (google's) recaptcha, which we're not using. I was thinking, if we could force the situation that's happening here, tell plasmo/parcel to not include, that would instantly resolve our issue too.

from date-fns.