WIP: split into src and package

[max-nextcloud]

• Target version: master (after the Nextcloud 24 fork)

Summary

In order to publish an npm package
and reuse parts of the text code in collectives
split the js source into

• src - for all things text specific, in particular webpack entries
• package - for the package, that is yet to be defined in package.json.

[vinicius73]

There are some eslint false positives.

[max-nextcloud]

There are some eslint false positives.

Yes... i am wondering how to tell eslint that the files are available in the package dir.

Figured it out. The eslint node extension does not know how to use resolvers. So we must disable it's warnings to only use the eslint import extension which uses resolvers just fine: 5adf417

[vinicius73]

We can move it to a local file and re-export it as a local component.
It will turn easier to adjust lazy load and other possible adjustments.

const EditorWrapper = () => import(/* webpackChunkName: "editor" */'@nextcloud/text-editor')

export default EditorWrapper

[vinicius73]

Also, we can access any exported value inside @nextcloud/text-editor.

const EditorWrapper = () => import(/* webpackChunkName: "editor" */'@nextcloud/text-editor')
  .then(package => package.default)

It is important because we are using named exports like store

import { store } from '@nextcloud/text-editor'

Lazy loading the default export and do not use lazy loading in named exports are incompatibles.

To make it, we must use lazy loading in named imports too.

const Store = () => import(/* webpackChunkName: "editor" */'@nextcloud/text-editor')
  .then(package => package.store)

But it does not make a lot of sense.
In our architecture, we can't use the async store without changing some parts of code and flow.

To make it possible we need to split the store and components into different parts/files of the @nextcloud/text-editor package.
It is possible, but I don't know if webpack will handle it well.

[max-nextcloud]

Well... it's possible - the store for example already is in a file of its own and importing just that file worked fine. I also noticed that highlight.js also uses paths into the package as more fine grained imports. So that seems to be an somewhat established option. Not pretty but maybe enough to get a first working iteration.

I might just use the file paths into the alias in src and then index.js to define the exports of the package that we can then use in collectives. I think there we just want the tiptap extensions for displaying the tables etc. nicely.

We might also want the editor wrapper to get rid of the magic we use to extract the editor component from the viewer. But that could be a separate step or we could just reference it by path to avoid bloating the read only editor in collectives if we include the EditorWrapper in index.js.

[max-nextcloud]

Open questions:

• how do we call the package / alias? @nextcloud/text-editor for now.

Next steps:

• create npm package (at least locally)
• use RichText extension to build the preview
• include css
• include css from text in collectives rather than having a copy
• allow customizing link handling in text.
• handle links inside a collective in collectives app.
• ensure all other links still work properly.
• publish 0.1.0 of the package.

Discarded:

• use EditorWrapper component to build editor in collectives rather than taking it from the view handlers
  If we compiled the editor into collectives it would differ from the one in text on older nextcloud instances.
  This way you could create tables in collectives - but they could not be rendered in text.
  It would also not be possible to share a session between the two.