Fix provided / injected extension list of BaseReader

[susnux]

• Resolves: https://gitlab.com/collectivecloud/collectives/-/issues/349
• Target version: master

Summary

BaseReader: Use a factory pattern for creating the extension list

Provide functions are neither called on the providing object nor
on the injecting object, so using this within provided functions
will refer to the global this for which $emit is not defined.
This uses a factory pattern so that this is bound to the injecting
object.

Also forwarding the click-link event is needed.

[susnux]

Rebased

[mejo-]

I tested the commit and it indeed fixes the issue in Collectives. Would prefer a second opinion on the actual code changes though.

[mejo-]

/compile

[max-nextcloud]

Code wise looks good to me and makes sense. Have not tested it though.

[mejo-]

Thanks so much for looking into this @susnux!

Could you push the compiled JS assets so the CI can run against them?

Also, if you don't mind, you could request to become part of https://github.com/nextcloud (to my understanding it's open to regular contributors). That way you could push your branches directly (no need to maintain a personal fork) and CI jobs would run automatically against your PRs.

[mejo-]

/backport to stable24

[vinicius73]

/compile amend

[mejo-]

@susnux unfortunately the node CI job fails because apparently the compiled assets have a diff after being recompiled in the CI.

We have the same issue in our development team and I'm not gonna lie: it's cumbersome and we need a better solution. But for us at least the /compile bot command can solve this by compiling the assets and pushing them to the PR branch. Unfortunately that doesn't work with PRs from external repos. That's why I suggested that you join the Nextcloud organization on Github and push your branches directly to our repo in the future.

I'm really sorry for this inconvenience and I hope that we're a better working solution soon.

Another option would be that one of our team pushes your branch to our repo and creates a PR. Just drop me a note if you prefer this option.

[mejo-]

So for this PR I just went ahead and opened a new one: #2662. At the same time, you should be invited to the Nextcloud Github organisation now @susnux, so in future things should be easier for you 🙈

[susnux]

@mejo-

unfortunately the node CI job fails because apparently the compiled assets have a diff after being recompiled in the CI.

Noticed that too. Even using exactly the same npm and node version as the CI does not work.
After some research I found that editor.js.map contains the path to the source file (absolute path) so for files built on my machine those paths include e.g. my username and that will defnetly differ from the CI build.

This seems related to: webpack/webpack#3603

Also, if you don't mind, you could request to become part of https://github.com/nextcloud (to my understanding it's open to regular contributors). That way you could push your branches directly (no need to maintain a personal fork) and CI jobs would run automatically against your PRs.

That required the invite so thank you for arranging this :)

So for this PR I just went ahead and opened a new one: #2662. At the same time, you should be invited to the Nextcloud Github organisation now @susnux, so in future things should be easier for you see_no_evil

Thank you!