Description
Environment
- Package version(s): 4.0.0-rc.0
- Browser and OS versions: Deno, Windows 10
Feature request
Implement early Deno support by supporting Deno's environment variable parsing methods.
Changes
The NS variable in @blueprintjs/core/common/classes.ts would need to support looking on both process.env and Deno.env for BLUEPRINT_NAMESPACE and REACT_APP_BLUEPRINT_NAMESPACE before falling back to the default. Here, I have implemented an example of this using a IIFE.
// only accessible within this file.
declare let process: { env: any };
declare let Deno: { env: { get(key: string): string | undefined } };
const NS = ((defaultNS)=>{
if (typeof process !== "undefined")
return process.env?.BLUEPRINT_NAMESPACE ?? process.env?.REACT_APP_BLUEPRINT_NAMESPACE ?? defaultNS;
if (typeof Deno !== "undefined")
return Deno.env?.get("BLUEPRINT_NAMESPACE") ?? Deno.env?.get("REACT_APP_BLUEPRINT_NAMESPACE") ?? defaultNS;
return defaultNS;
})("bp4");
The isNodeEnv function in @blueprintjs/core/common/utils/jsUtils.ts would also need to be expanded to encompass Deno's environment variables (at this time, the major one would be ALEPH_ENV = 'development' | 'production' from alephjs/aleph.js).
// only accessible within this file, so use `Utils.isNodeEnv(env)` from the outside.
declare let process: { env: any };
declare let Deno: { env: { get(key: string): string | undefined } };
/** Returns whether `process.env.NODE_ENV`/`Deno.env.get("ALEPH_ENV")` exists and equals `env`. */
export function isNodeEnv(env: string) { // rename to isRuntimeEnv?
return (typeof process !== "undefined" && process.env && process.env.NODE_ENV === env) ||
(typeof Deno !== "undefined" && Deno.env && Deno.env.get("ALEPH_ENV") === env);
}
The final piece in the puzzle would be @blueprintjs/core/common/configureDom4.ts. While this makes logical sense, it seems when processed through esm.sh that dom4 is loaded synchronously right at the start of the file which rightfully fails because Deno is not a browser environment. Even skypack.dev struggles with this dynamic import (Ctrl+F "dom4"). I'm not quite sure if this is something to be explored on your side or the side of the web bundlers. Currently I work around it by reaching into the locally cached version (at ./.aleph/development/-/cdn.esm.sh/v66/@blueprintjs/core@4.0.0-rc.0/deno/core.development.js) and forcing the dom4 module to be loaded using the __require helper method generated by the web bundler. This then prevents dom4 being loaded in Deno/Aleph while it's performing its SSR steps.