What is `import.meta.env.DEV` ??

[erights]

dapp-psm/src/installSesLockdown.js

Line 5 in ef56c8f

const consoleTaming = import.meta.env.DEV ? 'unsafe' : 'safe';

What is import.meta.env.DEV ??

There are no standard properties on import.meta, and Hardened JS's support for import.meta is still in flux.

[erights]

Attn @kriskowal @mhofman @FUDCo

[samsiegart]

It's from Vite (which I used for this dapp in place of create-react-app): https://vitejs.dev/guide/env-and-mode.html#env-variables

[kriskowal]

That’s clever. I suppose they have some reason why import.meta.dev might vary from module to module, perhaps because of hot module replacement and configuration changes, instead of invalidating every module when the global environment changes.

[erights]

During production, these env variables are statically replaced. It is therefore necessary to always reference them using the full static string. For example, dynamic key access like import.meta.env[key] will not work.

Weird!

@kriskowal , what do you think of this? How compat is this with Hardened JS and Endo?

[kriskowal]

We certainly can’t emulate import.meta at all in SES, but Vite is doing a server-side rewrite for all these that might pass produce a name that passes the censor.

I suspect the motive for the design is to have a special form that doesn’t have to be special all the time. That is, import.meta.env.x can be normal property access in the backend and rewritten to something else, as if interpolated in a template, when used in client-side.

This of course has nothing to do with import.meta in principle. The data is effectively global. It’s not clear to me that this couldn’t have been a global like process.env for portability.

[erights]

Is this rewrite possibly rewriting SES itself (or lockdown.umd.js or however it is that SES is packaged for this dapp)?