Unable to import constants from client-side components

[plaa]

Link to the code that reproduces this issue

https://github.com/plaa/next-import-from-client-component-bug

To Reproduce

1. Start the application in development (next dev)
2. Open the page
   --> The types of all constants imported from the client component are "function" instead of their respective types

Current vs. Expected behavior

If you import constants from a client-side component file, you receive functions, not the constants.

Simply having ClientComponent.tsx:

"use client";
export const CONST_STRING="string"

and importing it from page.tsx causes the imported constant to be a function instead of string:

import {  CONST_STRING } from "./ClientComponent";
export default function Home() {
  console.log(typeof CONST_STRING);
  return <p>{CONST_STRING}</p>;
}

Also TypeScript shows the type of CONST_STRING to be string.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Thu Sep 12 23:36:23 PDT 2024; root:xnu-10063.141.1.701.1~1/RELEASE_ARM64_T6031
  Available memory (MB): 36864
  Available CPU cores: 14
Binaries:
  Node: 20.14.0
  npm: 10.7.0
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 15.3.0-canary.13 // Latest available version is detected (15.3.0-canary.13).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.8.2
Next.js Config:
  output: N/A

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

Not sure

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

next dev (local), next build (local), next start (local)

Additional context

May be related to #66212 which should have been fixed by #66286 and #66990. Bug occurs in both latest release version 15.2.3 and canary.

A workaround is to move the constants to a separate file that is imported from both components, but that requires an additional file every time. Also the functionality is very unexpected and (as far as I can see) undocumented. Even TypeScript shows the type as the original const type, and the bug appears only at runtime.

[DWboutin]

Why don't you just have a contants.ts file?

[plaa]

Why don't you just have a contants.ts file?

That's the workaround. The constants changing when importing them from client components is extremely unexpected and AFAIK totally undocumented. Importing things should either work or cause an error/warning.

In our case we split every page into a SSR component in page.tsx and client-side ClientView.tsx. The ClientView takes as a prop only those localized labels it needs, and for this we need a list of all labels the page needs. This would naturally reside in the same file, but now we have to create a separate labels.ts for every page we create.

[DWboutin]

For me it's not a workaround, but good management of constants. Contants are constants, they should not change so it should not cause any troubles to have them in a separate file.

I'm not aware of your architecture tho.

[plaa]

These constants are tightly tied to the component in question, thus for me it's logical to place them in the same file as the component. The constant values will change as the component evolves.

[DWboutin]

My last message on this: If you are exporting it, you are using it elsewhere, so it's tied to another part as well. The good way would be to have a constants file, but you are the only person who knows what you really want.

I hope you will find a solution that will fit what you need.

[alexanderchr]

Surprised this bug hasn't been raised earlier. I think there are lots of cases where you'd want to put constants in the module that is being consumed instead of in a separate module.

I also ran in to this because I have a server action that handles image uploads. I need to validate the mime type both in the component that calls the server action as well as in the server action itself. The obvious place to put the list of mime types is in the server action, since it is very tied to this particular action. Ended up having to put it in its own file next to the server action, not very neat at all.