Secondary Entry Points fail resolve path

Type of Issue

[x] Bug Report
[ ] Feature Request

Description

I build secondary entry point for holding ngrx reducers/action/services, ng-packagr fail to build the relative path to entity in main library.

• Main library path motortrack-lib
• Secondary path motortrack-lib/services

export declare const selectTripEntity: import("@ngrx/store").MemoizedSelector<object, import("../../../../../../../dist/motortrack-lib/public_api").TripContract>;

the error is ng-packagr add an extra ‘…/’ on path

How To Reproduce

For reproduce just follow this entity adapter tutorial and implement it in secondary entry point lib.

In reducers i export entity as follow

// trips.reducer.ts
import {TripContract} form '@motortrack-lib'
// state

export interface State {
  selectedTrip: TripContract;
}

export const getSelectedTrip = (state: State) => state.selectedTrip;

then in index file i create a selector by importing that constant

index.ts
import * as fromTrip from './trips.reducer';

export const selectTripState= createFeatureSelector<fromTrip.State>('trips');

export const selectTripEntity = createSelector(
  selectTripState,
  fromTrip.getSelectedTrip
);

On the other hand if i put all in one file i don’t have any error because it use the imported contract from the top of the file

//trips.reducer.d.ts
export const selectTripEntity = import("@ngrx/store").MemoizedSelector<object,TripContract>;

Expected Behaviour

the extra ‘…/’ should not be added

Version Information

ng-packagr:            4.7.0
@angular/compiler:     7.2.2
rollup:                0.67.4
tsickle:               0.34.0
typescript:            3.2.4
@ngrx                  7.1.0

[evenicoulddoit]

I’m getting the same error as those reporting here, again with NgRx selectors, however if I’m reading the situation correctly this issue isn’t limited to secondary endpoints.

My build is failing on a secondary endpoint (mypackage/testing), but the error reported makes it clear that the issue is really with the definition file itself.

Simplified situation:

• @x/core package
• @x/sub package - has a dependency on @x/core
• @x/sub/selectors.d.ts produces relative and incorrect imports. They’re one level too deep (e.g. ../../../../dist/core/lib/xyz)

So, it appears that the definition files are the problem. As @rams23 has commented, updating all of the selector typings to explicitly declare their types is one solution, but both super ugly to do in mass, and also more difficult when using a feature adapter’s getSelectors() method.

Unfortunately I lack the specific package knowledge to tell if the issue lies:

• In NgRx’s selector definitions (given that all the issues to date have cited them)
• An issue with ng-packagr
• An issue with one of the multitude other libraries involve in a ng build call

[rams23]

If I explicitly import the type and I use in the selector ‘as’ like this:

import {RequestStatus} from '@mylib/core'

export const getDeleteLocationState = createSelector(
  selectProfile,
  state => state.locations.requestStatus as RequestStatus
);

it works fine but it is another workaround