DevTools in production from PR #44

[arjunvegda]

#44
Reference: #44 (comment)

[arjunvegda]

@sari-shipt - What version of NextJS, are you using? I'll try to reproduce it on my end. Also, I believe @blanky0230 is using CRA and not NextJS.

[arjunvegda]

Could you help us create a small repro in that case? Feel free to fork my CodeSandbox above ^

[SariSabouh]

The crazy part is that I did not face this issue either whenever I did it on CodeSandbox 🤔 ....

[arjunvegda]

Oh, so it's local only? Feel free to push it to a GitHub repo then

[SariSabouh]

It's happening to my company's project and it's a private repo unfortunately. So I can't share it. The CodeSandbox quick demo project I created worked just fine with the tree-shaking.

[SariSabouh]

The issue persists in my company's project without the process.env

[arjunvegda]

@dai-shi - What are your thoughts on adding a backward compatible check for process.env. to ESM modules until the industry fully adopts import.meta.env 🤔

Perhaps we could ship something like this?

((import.meta.env&&import.meta.env.MODE)!=="production" || (process?.env?.NODE_ENV)!=="production"))

[dai-shi]

well, that's very tricky and process? doesn't work.
is this only about jotai-devtools? or also jotai? (I kind of am aware import.meta.env.MODE doesn't work even with vite. So, I'm happy to think about some intermediate solutions. Maybe, with more complex export conditions)

[arjunvegda]

well, that's very tricky and process? doesn't work.

Ah, right! When you say "with more complex export conditions", do you mean exporting multiple variants of components each equipped with import.meta... and process.env...?

is this only about jotai-devtools? or also jotai?

Appears to be both actually 🤔. I verified it locally using CRA. Those debugPrivate labels from jotai are still being added when creating a prod build and wrapping them with process.env.NODE_ENV fixes it.

import.meta.env.MODE doesn't work even with vite

We just got another report that confirms this too

[dai-shi]

For vite, we need ask them to replace import.meta.env too. Do we have issues other than vite? We would need to configure "export conditions" for each case. import.meta is only available for ESM, and process is only available for node and some bundlers.

[arjunvegda]

Do we have issues other than vite?

We also got reports for Next JS and Create React App (mostly Webpack?) too.

Do most bundlers support production and/or development conditions? Could we use those?

Any thoughts on separate builds for browser and node? Here is a rough example

{
   "exports":{
      ".":{
         "node":{
            "import":{
               "types":"./dist/index.d.ts",
               "default":"./dist/index.cjs.js"
            }
         },
         "browser":{
            "import":{
               "types":"./dist/index.d.mts",
               "default":"./dist/index.esm.mjs"
            }
         },
         "types":"./dist/index.d.ts",
         "default":"./dist/index.cjs.js"
      }
   }
}

[dai-shi]

Yeah, I meant separate exports like that.
There are a few issues:

• New node should use ESM instead of CJS
• However, it's not common to use import.meta.env.MODE in Node, it's just Vite convention.
• But, even Vite can't handle (import.meta.env && import.meta.env.MODE) !== "production" as of now.
• Some bundlers (Webpack?) pick ESM, but they actually don't support ESM and transpile to CJS (import.meta causes an error).

So, unless we give up following Vite convention, we should provide ESM with process.env.NODE_ENV for this migration period.

We actually did so in v1 with "module" condition. (We still do in Zustand and Valtio.)
So, if we find good combinations of conditions, we can use it instead of "module".