Remove nextcloud scope from app name

[max-nextcloud]

Allow publishing an app and an npm package in the @nextcloud scope
from the same source.

[max-nextcloud]

For a bit of context:

We are working on packaging some of the text app for reuse in other apps (collectives for now, deck later). In order to ease development we want to keep the @nextcloud/text package and the text app in the same source tree.

We are considering to move to a monorepo with multiple package.json files - but for now we're building a dist folder for the package and js for inclusion in the app.

For the package we want to use the @nextcloud scope - for the app we want to avoid having an @nextcloud subdirectory in the js folder. So to be able to use the default config from this package we need to strip the @nextcloud/ prefix from the package name.

[skjnldsv]

We are considering to move to a monorepo with multiple package.json files - but for now we're building a dist folder for the package and js for inclusion in the app.

Careful about this, in the past we looked at this multiple times, and there is always a need for third party tooling, which make the management rather complicated iirc

[artonge]

Not sure that I fully understand the need and motivation here. Would having an additional repo for the package be that much of a burden?

[max-nextcloud]

... monorepo ...

Careful about this, in the past we looked at this multiple times, and there is always a need for third party tooling, which make the management rather complicated iirc

Yes - that's why were trying to avoid it.

[max-nextcloud]

Not sure that I fully understand the need and motivation here. Would having an additional repo for the package be that much of a burden?

The short answer is 'Yes.' 😉

Let me try to also explain the long answer.

Maintenance

First of all... it's not just another repo. It comes with a fresh git history, issue tracker, changelog, release cycle, test strategy and all that. We'd have the nextcloud/text repo and then the nextcloud/nextcloud-text repo? Sounds rather confusing than helpful to me.

We currently use backportbot-nextcloud for backporting fixes to previous versions. We still expect quite a bit of churn in the given part of the codebase as we just released a bunch of new features in NC 24.

Our current approach just adds a new build target and leaves the rest of our workflows as is. Moving the package to a separate repo would imply that we rewrite each fix by hand for the existing stable branches.

Package layout

What we want to achieve for now is to reuse code between Text and Collectives for rendering markdown. We mainly want to share css and tiptap nodes to make sure they look the same. We do so by exporting a single vue component called RichTextReader that receives the markdown via a content prop and renders it the way text would.

Text itself is not just a reader but an editor so it adds @nextcloud/vue components to certain tiptap nodes. For example the TableRow is rendered in a TableRowView that adds buttons to add table rows before and after and remove the row.
So if we want to build text on top of a package we're left with two options:

Minimal Package

Basically what we are packaging now - RichTextReader. But we would also have to expose all the tiptap nodes so text can add its buttons on top of them when using them in the Editor. So we would have to expose a lot more 'internals' of the package than we currently do.

Package most of text

We could also package the text editor alongside RichTextReader. This would keep the nodes and their extended views in the same repo. We'd need a package that can do tree shaking to only include the relevant parts of the package in collectives. I have not been able to build esm with tree shaking that include @nextcloud/vue components. I'll try again and open an issue in @nextcloud/vue about that.

Why have a separate repo?

Even assuming we manage to sort out the issues with a separate repo... what would the benefit of it be? It would save us the single line change to this repo - but besides that?

Creating packages from nextcloud apps

I actually think that building a package from a nextcloud apps source is a viable approach. Besides the reuse of the name in the webpack config i don't see any conflicting settings in package.json. We did not make use of files, main, module or type yet. In fact package.json so far is just for managing dependencies. I was able to move all dependencies not needed by the package into devDependencies without any issue thus far - but i might be missing something there.

[skjnldsv]

@max-nextcloud can you raise that issue at https://github.com/nextcloud/standards ?
I think this would benefit from collectively take a decision on this?

[max-nextcloud]

@max-nextcloud can you raise that issue at https://github.com/nextcloud/standards ? I think this would benefit from collectively take a decision on this?

I opened nextcloud/standards#3 to start a discussion there.

However for now i don't necessarily want to turn this into a standard just now. I'd be happy to try it out with text for a release cycle or two and see if it works for us. This might help inform the discussion.

[vinicius73]

Just a small idea to improve this implementation.

[vinicius73]

Unfortunately, it can create unpredictable behaviors across all our apps ecosystem.
Instead of change it directly, we can export this object as a function (in other file maybe) and using parameters change the appName

config.js

const buildConfig = ({ appName }) => {
  return {
    // ommited
    output: {
      publicPath: path.join('/apps/', appName, '/js/'),
      filename: `${appName}-[name].js?v=[contenthash]`,
    }
  }
}

module.exports = { appName }

in webpack.config.js

const { buildConfig } = require(./config.js)

const appName = process.env.npm_package_name

module.exports = buildConfig({ appName })

We will be able to import buildConfig instead of webpack.config.js into the applications and be able to do other changes like different output paths if we want.

[max-nextcloud]

I'm starting to think the appname should be taken from appinfo/info.xml.
The really crucial part in the webpack.config.js is

{ publicPath: path.join('/apps/', appName, '/js/'), }

My understanding is that this povides the path to fetch the js files from. I'm pretty sure which path is understood by the server does not depend on the package.json but on the appinfo.

[juliushaertl]

Isn't that public path anyways overwritten by __webpack_public_path__ as the /apps/ will not work as a static location in case multiple app directories are used?

[skjnldsv]

My understanding is that this povides the path to fetch the js files from. I'm pretty sure which path is understood by the server does not depend on the package.json but on the appinfo.

We expect developers to use the same name in npm pkg AND appinfo :)
Not all repo using webpack-vue-config are apps btw, so no appinfo here 😉

[max-nextcloud]

As said in nextcloud/standards#3 (comment) we prefer to have two package.json now to also avoid confusion with dependencies