Is Using `__deps__` for Module Dependencies in ESM a Smart Move?

I've been experimenting with a new approach to handle module dependencies in a way that works across different runtimes, like Node.js and the browser. Instead of using standard import statements, I want to declare dependencies as data in my module. Here's an example:

```js
export const __deps__ = {
fs: "node:fs",
logger: "./logger.mjs",
};

export default function makeService({ fs, logger }) {
// ...
}
```

With this setup, the module doesn't import anything directly, but instead, it gets its dependencies passed from a higher level in the application. For example:

In Node:
```js
makeService({ fs, logger });
```

In browsers:
```js
makeService({ fs: fsAdapter, logger });
```

This pattern is similar to standard Dependency Injection, and my goal is to keep the modules flexible and runtime-agnostic. However, I'm aware there are trade-offs, like reduced static analyzability and the need for more architectural discipline. So, do you think this pattern is a valid approach for cross-runtime modules, or is it just unnecessary complexity compared to using import maps or conditional builds?