generate:types Unknown file extension ".png" error

[benjaminpreiss]

Describe the Bug

Importing a *.png file in a block works fine, except when the need arises to regenerate the types.
This issue is the exact same issue as #7927, except some further clarification on the issue is required.

In my opinion, it should be possible to import image files from other folders than /assets for better project structure and to leverage image size optimizations.

Link to the code that reproduces this issue

https://github.com/benjaminpreiss/payload/tree/main

Reproduction Steps

Use node 20!

1. Clone repo
2. Checkout branch png-import-bug-generate-types
3. cd png-test
4. pnpm i
5. pnpm generate:types

Which area(s) are affected? (Select all that apply)

Not sure

Environment Info

Binaries:
  Node: 20.12.2
  npm: 10.5.0
  Yarn: 1.22.19
  pnpm: 9.0.4
Relevant Packages:
  payload: 3.9.0
  next: 15.1.0
  @payloadcms/db-postgres: 3.9.0
  @payloadcms/email-nodemailer: 3.9.0
  @payloadcms/graphql: 3.9.0
  @payloadcms/next/utilities: 3.9.0
  @payloadcms/payload-cloud: 3.9.0
  @payloadcms/richtext-lexical: 3.9.0
  @payloadcms/translations: 3.9.0
  @payloadcms/ui/shared: 3.9.0
  react: 19.0.0
  react-dom: 19.0.0
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10

[benjaminpreiss]

Looks like payload uses native TS import to import the config.
Naturally, this fails for .png files, as they cannot be resolved by native node import statements.

I can see two options based on this analysis:

• Run a bundler on config before importing it (esbuild would be a suitable option for example).
• Scrap this feature and require people to dump their assets in /assets folder

I prefer the first option, as the second option eliminates image optimizations (I think). So if I use huge images, the editing experience might suffer?

[AlessioGr]

Hi, I'm converting this to a discussion as I wouldn't consider this a bug in payload. The Payload Config, by us, is treated as and expected to be 100% node-safe. Getting anything that's not node-safe to work would be the responsibility of the user => thus not an "issue"