4

I am unsure what is really to blame for this issue. I think it's Typescript, but it could be ng-packagr or Angular. It only started when I updated to Angular 9.

Here is the message I get on my production build... 

WARNING: Conflicting namespaces: dist/web-apps-shared/esm2015/public_api.js re-exports 'ɵ0' from both dist/web-apps-shared/esm2015/lib/api-applications/reducers.js and dist/web-apps-shared/esm2015/lib/account-codes/reducers.js (will be ignored)

Here is one of the sources that is causing this...

export const selectTotalAccountCodes = createSelector(selectSharedAccountCodeState,
  (state: SharedAccountCodeState) => state.totalItems);

The compiler for some reason takes the function parameter and assigns it to a const and then exports it like so...

const ɵ0 = (state) => state.totalItems;
export const selectTotalAccountCodes = createSelector(selectSharedAccountCodeState, ɵ0);
export { ɵ0 };

The question I have is, why does ɵ0 need to be exported? It is only used internally in this file. I am I missing something? Should worry about this? It doesn't seem to be causing an issue when consuming the library that is built with this code.

Geo242
  • 451
  • 5
  • 13

1 Answers1

7

I've got the same warning while updating to Angular 9, looking on the web for some info/solutions I've also found this Angular issue page https://github.com/angular/angular/issues/33668 ( 11/2019 so 3 months ago ), where they say that is an Ivy's issue, something related to the "export * ".

This is strange since I need to publish to npm and build recommendation says to disable Ivy , so I've disabled it ( angularCompilerOptions.enableIvy false in tsconfig.lib.json ): instead, set enableIvy to true makes the warning disappear.

So I did this try, while keeping enableIvy set to false in tsconfig.lib.json, in the public-api.ts I've modified the "export * " replacing the "*" with all the exported objects, one by one: warning is gone, the library is working.

But I really don't know if this is a good fix or if it is better just to show the warnings..

Sergio Rinaudo
  • 2,303
  • 15
  • 20
  • 1
    Regarding the topic whether it's a good approach or not: According to a comment by [one of the angular devs](https://github.com/angular/angular/issues/33668#issuecomment-555973301) in Nov. 2019, manually re-exporting all objects one-by-one in angular libs is the currently desired approach. So this answer should be the correct one – Capricorn Jul 26 '20 at 10:17