Meaning for this library if we include the path polyfills you still need the polyfills in your app config because this library depends on e.g. @nextcloud/files which makes heavy use of the path module.

Gotcha, didn't know we use it in files too.

So I would prefer if we can agree on a common practice across @nextcloud/ libraries for handling node modules.

Yeah this makes total sense. From my side, the reasons I think we should move away from node polyfilling:

This code is only ever supposed run in the browser, so polyfilling node functionailty is semantically not right. This code is never supposed to run in node, so it makes no sense to use node APIs.
It adds transitive dependencies that we don't need (e.g. process)
(most important) this causes the library to depend on the webpack configuration of the downstream plugin. Further, no idea what happens if the downstream app wants to switch to something other than webpack. The libraries should be as independent as possible.

Need input from more people on this. @skjnldsv any comments?

BTW the webdav client used to depend on node polyfills earlier, but that dependency too is gone in the latest version (they split node and browser modules).

Dependencies on node APIs #1126

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions