ng-packagr: TypeScript paths not resolved

Hi, this is expected and this is by TypeScript design. Paths don’t get re-rewired when emitted.

Hence, when building a library you should only use paths to change the location of an external module lookup. Not to make an import look clean.

When using nice imports like @app/foo This works in an application because of tools such as webpack as running the javascript code directly won’t work as it’s not valid.

Ideally you should not output js code that doesn’t rely on tooling to work. Hence I would strongly discourage using paths to shorten the import and make them look clean.

paths Ideally should be used to change the resolutions and not to change the module import statement.

Add index.ts file to your library folder next to public_api.ts file, and move all exports to index.ts file.

Update public_api.ts file to the following:

export * from './index'

This should make both ng-packagr and TypeScript happy.

News on this? I can’t believe there’s no solution!

Same issue

src/app/core/store/index.ts(2,39): error TS2307: Cannot find module '@core/store/admin/calculation-rules/calculation-rules.reducer'.
src/app/core/store/index.ts(3,27): error TS2307: Cannot find module '@core/store/admin/functionn/functionn.model'

tsconfig.json

“baseUrl”: “./”, “paths”: { “@environments/": ["src/environments/”], “@core/": ["src/app/core/”], “@shared/": ["src/app/shared/”] }

“ng-packagr”: “^3.0.6” “typescript”: “2.9.2”

It seems that this is a problem even in the example ng-packaged app. I just cloned it today, did an npm install and the ng serve works fine. But if you open src/app/app.component.ts, the import import { BarService } from '@my/lib'; says [ts] Cannot find module '@my/lib'.. I tried adding the index.ts like you sais @Karankang007 , but I get the same error. This would be very problematic for development of a library if it can’t resolve the components.

A temporary solution is to build your librairies without intra package dependencies inside your node_modules. After that, you can build all packages with a reference of your others intra packages.

"ngPackage": {
    "lib": {
      "entryFile": "public_api.ts"
    },
    "dest": "../../node_modules/@scope/lib-A/"
  },

Any solution on this?

There’s no valid solution to this problem.

Lot’s of hand waving but none of the code in this thread actually works.

Building a library and I’m in relative path hell, all my imports look like this and no way to fix it by using a token defined in tsconfig paths

import { VinDecodeService } from '../../../services/vin-decode/vin-decode.service';

I tried hundred times to get this import to not suck. Just want it to look like this:

import { VinDecodeService } from 'src/services/vin-decode/vin-decode.service';

I tried using @dynatron/framework for the path token instead of src since that’s what is defined in package.json, that did not work.

Every time VSCode editor try to automatically add an import it screws it up. Have to manually go put in bunch of dot-dot-slash’s, it is real painful coding experience. Hope there is some way to recognize paths of tsconfig.

You cannot create paths in tsconfigs and import them unless they are secondary entrypoints, ie they have a package.json and an ng-packagr configuration.

This is because from a consumer perspective it is impossible to resolve such entries and typescript won’t rewrite these during compilation.

Building a library is not the same as building an application.

If you want to reference files which are not relative, you need to create secondary entry points as explained here; https://github.com/dherges/ng-packagr/blob/master/docs/secondary-entrypoints.md

This is to have something like

import { foo } @my-lib/testing;
import { bar } @my-lib;

Not that @my-lib and @my-lib/testing are defined in package.json

I am using ng-packagr v 3.0.6 and same error occurs as per the screenshoots…

thank you,

I am seeing that you are using an old version of ng-package. This was solved in v3+

On Mon, 06 Aug 2018 at 14:48, Bilal ElDabet notifications@github.com wrote:

@klemenoslaj https://github.com/klemenoslaj made repo for it https://github.com/klemenoslaj/ng-packagr-bug-example I have the same issue as his ( Cannot find module ‘@example https://github.com/example /example’ )

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dherges/ng-packagr/issues/519#issuecomment-410696426, or mute the thread https://github.com/notifications/unsubscribe-auth/AQv-WorR9OZgTkW1x60sVf1p1ZFPPDr8ks5uODsggaJpZM4Rl7KV .

Hello… Any Update on this issue? I still have Cannot find module @example /example thank you…

When using nice imports like @app/foo This works in an application because of tools such as webpack as running the javascript code directly won’t work as it’s not valid.

Seems like rollup has a similar tool https://github.com/rollup/rollup-plugin-alias

Has anyone tried integrating this?

At my work we have the use case of wanting to integrate various Angular UIs from separate repos into a new app a la micro-frontends, via lazily loaded Angular libraries. All of the UIs have been written to use paths (a best practice), so I will be working on being able to build libraries out of such code, one way or another. It’s a must for us.

Hi, not sure if this is the same issue as it sounds very similar (let me know if it isn’t and I’ll raise another one). “https://github.com/klemenoslaj/ng-packagr-bug-example” is not the same.

In a regular angular project, the “paths” property of tsconfig.json allows you to reference modules using cleaner imports (i.e. control the amount of nesting). Examples commonly seen are @app, and @env. I’m not entirely familiar with how the build is generated, but essentially these paths resolve correctly. They behave as aliases and are interchangeable with relative paths (let me know if this is not the case).

With ng-packagr, I want to use the same path scheme within the library. Adding the aliases (@app) to tsconfig.lib.json allows the library to be built. However the alias path @app remains in the generated fesm5 and fesm2015 javascript files.

Using the lib in a new angular app results in a module not found error. If I were to replace the @app with the equivalent relative path, the fesm5 and fesm2015 appears to ‘inline’ the reference modules.

I do not need or want to expose the internal modules of the library as secondary entry points. It would be good if they can remain internal. However, I could not find a way to do this while still using alias paths (avoiding relative paths) within the library.

Please let me know if that makes sense, and whether it is the same issue being discussed. Even better if you have a solution to this.

Dear @alan-agius4 ,

Here’s a sample of what I’m trying to do: https://github.com/bilaldabet/ngPackgrTest

I think the problem is from my side, can you please Guide me.

Thank you,

@jRichardeau you can use the ng-packagr api directly with a custom tsconfig.

Please look at the example here: https://github.com/dherges/ng-packagr/tree/master/integration/samples/api

That is fine by me. Will change my source after the release. Great, nice work! 👍