@gjsify/resolve-npm 0.13.1 → 0.14.0

package/lib/index.mjs

@@ -441,8 +441,31 @@ export const ALIASES_GENERAL_FOR_NODE = {
     '@gjsify/web-globals/register/formdata': '@gjsify/empty',
 }
 
-/** Record of Gjs modules (build in or not) and his replacement for Node */
-const ALIASES_GJS_FOR_NODE = {}
+/**
+ * Record of GJS built-in module specifiers and their replacement for the
+ * `--app node` target. These are the bare ESM module names a GJS source imports
+ * (`import System from 'system'`, `import Gettext from 'gettext'`) — GJS exposes
+ * them as built-in modules; Node has no equivalent, so on the node target they
+ * route to the `@gjsify/node-gi` reverse-bridge shims, which are kept EXTERNAL
+ * (resolved at runtime against the consumer's node_modules — see
+ * `app/node.ts`'s external set), never bundled. This is the analogue of the
+ * `gi://` rewrite + `@gjsify/node-gi/globals` injection, and like them it is
+ * NODE-TARGET-ONLY: the gjs/browser/nativescript alias maps do not include this
+ * record, so a bare `system` / `gettext` import keeps resolving natively (GJS
+ * built-in / npm package) on every other target. The risk of hijacking a real
+ * npm package literally named `system`/`gettext` is identical to (and bounded
+ * the same way as) the `gi://` design: it only applies when building a GJS/GI
+ * source for Node.
+ *
+ * `cairo` is intentionally NOT mapped — it needs a real Cairo binding (out of
+ * scope here), so it falls through to the normal resolver (a `cairo` npm package
+ * resolves as usual, an unresolvable bare `cairo` surfaces as a build error
+ * rather than silently no-op'ing).
+ */
+const ALIASES_GJS_FOR_NODE = {
+    'system': '@gjsify/node-gi/system',
+    'gettext': '@gjsify/node-gi/gettext',
+}
 
 export { ALIASES_GJS_FOR_NODE };
 

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@gjsify/resolve-npm",
-    "version": "0.13.1",
+    "version": "0.14.0",
     "description": "Resolve NPM package aliases",
     "type": "module",
     "main": "lib/index.mjs",