Nx: Using public_api.ts in libraries instead of piling everything in index.ts

Created on 13 Dec 2017  路  5Comments  路  Source: nrwl/nx

My suggestion, and what I've been doing, is creating a public_api.ts along-side the index.ts. You can see an example of it being done in the @angular repo.

It would be used to bring all your exports together from a library in once place.

Example:
public_api.ts

export { ProductApiModule } from './src/product-api.module';
export { Product } from './src/models/product';

import * as productActions from './src/actions/product';
import * as fromProduct from './src/reducers/product';
import * as fromFeatured from './src/reducers/featured';
export { fromProduct, fromFeatured, productActions };

index.ts

export * from './public_api';
feature

Most helpful comment

I really like the idea of two (2) separate files for intent:

  • public_api.ts is intended to enumerate and expose specific functionality for external use.
  • index.ts is intended as a default exporting mechanism to deprecate full-path imports.

I have had lib scenarios where my public_api exports were different than my barrel exports.

For onboarding developers, the public_api.ts clear identifies the public api.

All 5 comments

I see this pattern in angular/core and angular/material, this was also asked from @jschwarty at ng-houston few days ago. Can you explain what are the benefits of this pattern in comparison to do these exports in index.ts?

Does anyone know why it's a convention in Angular projects? From what I remember, this was to facilitate scripts and make it possible to disambiguate between true public API and public API+private symbols that needed to be exported so other Angular packages could use them.

IMO, the convention doesn't add enough value to justify the cost of having two files.

I really like the idea of two (2) separate files for intent:

  • public_api.ts is intended to enumerate and expose specific functionality for external use.
  • index.ts is intended as a default exporting mechanism to deprecate full-path imports.

I have had lib scenarios where my public_api exports were different than my barrel exports.

For onboarding developers, the public_api.ts clear identifies the public api.

@ThomasBurleson I'm not sure that having two files would allow you to access "private exports" without maintaining two sets of path mappings. Unless I'm missing something.

As far as I'm aware, the Angular repo now relies on to express a "private export", so having two files isn't necessary. All index files in the angular repo just reexport public_api. I think we should do the same. If you want to export something that is not meant to be used, just prefix it with .

Maybe someone can come up with a good example (an nx repo) showing how having two files is easier in some way?

Closing this

Was this page helpful?
0 / 5 - 0 ratings