Circular dependency in rollup project

Hello there,

I’m working on a Solid Obsidian Plugin and running into a puzzling issue:

While building the code, I get:

node_modules/@inrupt/solid-client/dist/rdfjs.internal.mjs → node_modules/@inrupt/solid-client/dist/datatypes.mjs → node_modules/@inrupt/solid-client/dist/rdfjs.internal.mjs
node_modules/n3/src/N3DataFactory.js → node_modules/n3/src/N3Util.js → node_modules/n3/src/N3DataFactory.js

Trying to run my plugin in Obsidian now crashes, giving me:

Plugin failure: xxxxxx TypeError: Class extends value undefined is not a constructor or null
at anonymous (duplexify.js:50:25)
at e. (app.js:1:1547485)
at app.js:1:235078
at Object.next (app.js:1:235183)

Has anyone already faced such circular dependency errors? Any idea on how to debug this?

Candide

This seems related to readable-stream upgrade breaks build · Issue #310 · rdfjs/N3.js · GitHub rather than being an issue with circular dependencies. Could you open a new issue in GitHub - rdfjs/N3.js: Lightning fast, spec-compatible, streaming RDF for JavaScript reporting this?

Can you also try adding

  "overrides": {
    "n3": {
      "readable-stream": "3.6.0"
    }
  }

To your package.json and report whether that fixes the error or not? This would indicate whether it is caused by a breaking change in the readable-stream package.

Thank you for the quick update. I created the issue here. Unfortunately, the override doesn’t fix the problem.

1 Like

Here’s a quick repro repo that demonstrates the issue: GitHub - ckemmler/solid-circular-dependencies: repro repo demonstrating circular dependencies with inrupt libraries

UPDATE: there was an error in my previous message; I reported the issue to the n3 repo here

That being said, it is possibly related to the inrupt libraries as well.

Hi from the Developer Tools team at Inrupt, we’re aware of these circular dependencies, however, we’ve never yet seen these be a source of a crash during builds or usage of our SDKs (though I did start work a year ago to attempt to resolve, it’s tricky without potentially breaking API, something we avoid as much as possible)

1 Like

Hi Miss Em,

Thank you for your reply. Indeed I can see that this wasn’t really a problem and I am still trying to identify the root cause of the many issues I’m having since I introduced the inrupt libraries in my project.

At this point, it looks like the simples first issue I am able to nail down is the one I documented here: crypto.getRandomValues() not supported. · Issue #2550 · inrupt/solid-client-authn-js · GitHub. (I provide a simple repository that demonstrates it here)

I am suspecting something rather deep-rooted, as it looks that, whatever I try to do in my setup is doomed to fail somehow… but I can’t quite put my finger on it, yet.

I’ve replied to that issue.

1 Like

Thank you. And I just replied. Unfortunately using @inrupt/solid-client-authn-node instead of @inrupt/solid-client-authn-browser doesn’t solve the issue.

Summary for anyone else finding this thread, the warnings were exactly that, and the issue faced appears to have been due to the build tooling being used (looked like it was building for browser but trying to be run in node.js, where different APIs exist for now)

To be a little bit more precise, the build tool is rollup.js in this case. And the one thing that had everything collapse in unpredictable ways is the use of a plugin to this build tool, namely nodeResolve. Even if everything is reset to target node exclusively (thus not browser), in my case, the code does not work. Essentially it looks like one of this plugin’s side-effects is that it will rename some global dependencies; e.g. crypto will be renamed crypto_1, and thus any code that refers to crypto from the global context will crash.