Dist files contain references to @nextcloud/typings put is not declared as peer dep

[skjnldsv]

Example: https://www.runpkg.com/?@nextcloud/l10n@2.1.0/dist/registry.d.ts

Importing and building might/will generate errors in other libs if they don't use @nextcloud/typing themselves

Ref nextcloud-libraries/nextcloud-files#621
cc @ChristophWurst @susnux

[susnux]

I am still not sure if peer dependency or plain dependency is the correct way, what do you think?

[skjnldsv]

Peer is automatically installed if you import the library.
Runtime is not really fitting here too as this is for typings only 🤔

[ChristophWurst]

Peer means it's pushed down as dependency of packages that require this package. I don't think that is necessary. The typings are a dev dep of this package.

[skjnldsv]

But they end up in the dist folder. Which still generates errors for other packages.

[ChristophWurst]

Same issue with the router

> tsc

node_modules/@nextcloud/router/dist/index.d.ts:1:23 - error TS2688: Cannot find type definition file for '@nextcloud/typings'.

1 /// <reference types="@nextcloud/typings" />
                        ~~~~~~~~~~~~~~~~~~

[ChristophWurst]

If typings are part of dist, doesn't that even make them regular dependencies?

Peer dependencies might create a dependency hell. Imagine we have to packages @nextcloud/a and @nextcloud/b. @nextcloud/a depends on typings v3, @nextcloud/b uses typings v4. If they had the typings as peer dependencies, an app would not be able to install a and b because it would become impossible to satisfy both a's and b's requirements.
If the typings are dev dependencies, they do not get installed.
If the typings are regular dependencies then npm's deep hierarchy allows the parallel installation of typings in v3 and v4.

[ChristophWurst]

We also can't be the first ones to run into this. I'm sure other packages faced the same challenge.

[ChristophWurst]

https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#dependencies so regular dependencies it is.