webpack support

[ayroblu]

Summary

Hi, I noticed that window.__NUMBER_OF_JOTAI_INSTANCES__ was injected into our console. From a look at the details, I'm guessing that this is a vite thing where they inject an environment variable. However we use webpack that doesn't have this automatically happen. Is there a way to handle the traditional webpack case (where it would typically use process.env.NODE_ENV === 'production')

Link to reproduction

N/A

[dai-shi]

This is a one-size-does-not-fit-all situation.
I thought it would be nice for ESM build to be Node.js process free. Thus, it uses Vite convention.
Our CJS build still uses traditional process.env.NODE_ENV style.
We used to have module condition for webpack, which is dropped in v2. #1675
I wonder if webpack supports webpack condition or something.

Anyway, I will think about it and if anyone has some expertise, feel free to jump in.

[ayroblu]

I was thinking that the check here:

jotai/src/vanilla/store.ts

Line 848 in 3ca1d43

if (import.meta.env?.MODE !== 'production') {

changes from:
if (import.meta.env?.MODE !== 'production') {
to
if (import.meta.env && import.meta.env.MODE !== 'production') {

So that the "default" is guess production if not vite rather than the reverse

[dai-shi]

Please see https://unpkg.com/browse/jotai@2.7.0/esm/vanilla.mjs for the transformed code.

We used to make the default guess to be production, but with that many people missed warning messages and reported many issues, so we changed the default guess to be development.

[dai-shi]

By the way, one reason for the transformation is that our "src" code is to work with Deno.

[dai-shi]

I guess one workaround is to use cjs build with require().

const { atom } = require('jotai');

If you don't prefer the require syntax, I think you can configure webpack to use cjs build instead of esm.

Though, our cjs build is es5, so it might not be ideal.
When we move to Jotai v3, we probably drop es5, like pmndrs/zustand#2380.

I wonder if there a way to configure webpack so that it replaces import.meta.env.

[ayroblu]

webpack/webpack#15833
Not really yet, there's one example of a loader, but that's just rewriting the ast, which is reasonable but not an ideal final solution: https://github.com/XiaoLin1995/import-meta-loader/blob/main/src/transform.ts#L78-L80

I think there should be a way to support both syntaxes until this stuff becomes standardised

[dai-shi]

Can you try require() in the meantime and see if it works? (I'm also interested in how much the bundle size would increase.)

[ayroblu]

I think this isn't what we're gonna do, I do have a way in webpack to exclude it, but I already shipped the dev experience to prod, which is fine but a bit unfortunate. I just think that the default should be handled a bit better

[dai-shi]

Until webpack/webpack#15833 lands,
#2434 is an attempt to provide a specific build for webpack.
It's with webpack export condition. It should be easier to configure (than using cjs build), even if it's not officially supported.

https://ci.codesandbox.io/status/pmndrs/jotai/pr/2434
☝️ See "Local Install Instructions"

[ayroblu]

yarn add v1.22.17
info No lockfile found.
(node:39700) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
[1/4] 🔍  Resolving packages...
error An unexpected error occurred: "https://pkg.csb.dev/pmndrs/jotai/commit/e4090cee/jotai: Request failed \"500 Internal Server Error\"".
info If you think this is a bug, please open a bug report with the information provided in "/Users/blu/ws/temp/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.