Library with secondary entry points only

[klemenoslaj]

Type of Issue

[ ] Bug Report
[x] Feature Request

Description

Would it be good idea for ng-packagr to support a library consisting of secondary points alone?
Something like @angular/material is doing.

How To Reproduce

n/a

Expected Behaviour

@angular/material is a library that inspires a lot of other libraries, I am sure. Would it not be a good idea to support their structure?

Example:

| - library
  | - component-a
  | - component-b

Could result in @org/library/component-a and @org/library/component-b.

Version Information

n/a

[paulayo93]

Currently challenged by this issue. Is it possible to have the feature included?

[paulayo93]

Please is there a temporary workaround for this type of issue (as described by @klemenoslaj ) using ng-packagr?

Thanks for the help!

[JoostK]

What's the problem here, exactly? @angular/material does have a primary entry-point, it's just empty. Would that not be a possibility with ng-packagr for some reason?

[klemenoslaj]

Last time I tried having empty primary entry-point the build failed (worked after exporting some fake variable). I did not try it since, but can try again later today with latest version.

[JoostK]

@klemenoslaj ah, I see. I can't think of any changes in this area, so I expect that to still behave the same. As you said, exporting a dummy could be a workaround.

[klemenoslaj]

@klemenoslaj ah, I see. I can't think of any changes in this area, so I expect that to still behave the same. As you said, exporting a dummy could be a workaround.

Yes, that's what I currently do. It is a bit awkward tho :)
I could contribute if empty endpoint is something you would want to support.

[SchnWalter]

Just to add a note, we already have an undocumented support for empty "secondary entry points", which allows us to have a library that skips "one level" in the sub-package path:

@example/package
@example/package/core
@example/package/components/badge
@example/package/components/toggle
@example/package/components/toggle/testing
@example/package/components/testing/integration

Notice the missing @example/package/components and @example/package/components/testing sub-packages, see comments on: #1748 (comment)

This feature would be similar to that, if official support is added for such a feature, we should probably deal with these features in the same MR.

[leolio86400]

It is a fairly common issue from monorepo structures.

Ended on that few weeks ago, would it make sense to use this feature instead of having package.json everywhere?
https://nodejs.org/api/packages.html#packages_subpath_patterns

[SchnWalter]

We can't use the subpath pattern because we have more data in our secondary entry point package.json files, and that pattern can't expose such data:

# cat package.json
{
  "main": "../bundles/myorg-mylib-subpackage.umd.js",
  "module": "../fesm2015/myorg-mylib-subpackage.js",
  "es2015": "../fesm2015/myorg-mylib-subpackage.js",
  "esm2015": "../esm2015/subpackage/myorg-mylib-subpackage.js",
  "fesm2015": "../fesm2015/myorg-mylib-subpackage.js",
  "typings": "myorg-mylib-subpackage.d.ts",
  "sideEffects": false,
  "name": "@myorg/mylib/subpackage"
}

[wojtek1150]

Just add ng-package.json and public-api.ts file into component-a folder. In root public-api file paste

export default void 0;

Should works as expected ;)

[johncrim]

I use this in the root public-api.ts:

// public-api.ts is required by ng-packagr and cannot be empty.
const DO_NOT_IMPORT = 'Do not import from @myorg/mylib; Submodules must be imported directly.';
export default DO_NOT_IMPORT;

But otherwise, same fix.

[tomavic]

Would you consider this as a best practice, using the public-api.ts file and re exporting all secondary entries instead of exporting fake string (which I always do xD )