TypeScript paths not resolved

[klemenoslaj]

Type of Issue

[x] Bug Report
[ ] Feature Request

Description

TypeScript paths do not get resolved when executing ng-packagr -p ng-package.json.
Paths get resolved normally on ng serve(I am using Angular Cli).

How To Reproduce

• clone repository: https://github.com/klemenoslaj/ng-packagr-bug-example
• install dependencies with yarn or npm install
• execute npm script build:lib

Error
Cannot find module '@example/example'

Expected Behaviour

Should be no error. Imports should work as they work with ng serve.

Version Information

ng-packagr: 1.6.0
@angular/*: 5.2.1
@angular/cli: 1.6.5
typescript: 2.5.3
rxjs: 5.5.6
node: 9.4.0
yarn: 1.3.2

[JoostK]

ng-packagr is completely separated form the CLI and does not follow its behavior. More specifically, the project's tsconfig.json file is not used at all in ng-packagr, it has its own specific tsconfig to compile with given that the configuration must meet certain standards.

There is currently work being done by @dherges to allow for overriding specific tsconfig settings. This feature has just landed last week. I'm unsure about its current status and available examples at the moment. You may also look into using yarn link to symlink certain modules, that's what I have good experience with (although it gets unwieldy with many packages)

[deebloo]

what @JoostK said. You will need to wait for a release to pass in your own tsconfig

[klemenoslaj]

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

[NeoLSN]

Building Angular Package
Building from sources for entry point 'app-engine'
Cleaning build directory
Extracting templateUrl and styleUrls
Processing assets
Inlining templateUrl and styleUrls
Compiling with ngc
Writing flat bundle files
Bundling to FESM15

BUILD ERROR
Could not resolve './core/app-engine.module' from .ng_build/app-engine/out/index.js
Error: Could not resolve './core/app-engine.module' from .ng_build/app-engine/out/index.js
    at error (<project_root>/node_modules/rollup/dist/rollup.js:170:15)
    at <project_root>/node_modules/rollup/dist/rollup.js:18717:25
    at <anonymous>

I'm confused about this issue.
My situation is

• This library is a tar.gz file and it use ng-packagr to build itself. It will start to build itself after installing.
• If I use typescript@2.5.3, it goes fine.
• If I use typescript@2.6.2, it will be failed and that error message as mentioned above.

Did someone know what wrong in here?

[jRichardeau]

I need nearly same feature, I have in my projects some files for testing, but ng-packagr tries to read and include them in the component, so I would like to exclude or include some files/directories from the process.

Moreover doesn't ng-packagr following the dependencies included in public_api.ts ?
If yes it could not try to package my other files because they are not included in my public_api nor its dependencies.

Thank you

[karan-kang]

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.

[belamrani]

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/"
  },

[wallace41290]

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.

[jRichardeau]

@Karankang007 thank you for your answer but this is not my problem.

My problem is that ng-packgr tries to build files which are in my "tests" folder, and I can't exclude them from the build process.

[karan-kang]

@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

[Chris3773]

@Karankang007 This option doesn't work when using secondary entry points as they do not use the passed in tsconfig file.

[alan-agius4]

@Chris3773, can you explain a bit further as secondary entry points do use the tsconfig provided by the API. Though it was used as read from the primary entry point.

[Chris3773]

I copied the tsconfig that ng-packagr uses and added paths and lib.

{
	"compilerOptions": {
		"target": "es2015",
		"module": "es2015",
		"moduleResolution": "node",
		"outDir": "",
		"declaration": true,
		"sourceMap": true,
		"inlineSources": true,
		"skipLibCheck": true,
		"experimentalDecorators": true,
		"emitDecoratorMetadata": true,
		"importHelpers": true,
		"baseUrl": ".",
		"paths": {
			"@scope/project-name/*": [ "lib/*" ]
		},
		"lib": [
			"es2015",
			"es2017",
			"dom",
			"scripthost"
		],
		"allowUnreachableCode": false,
		"allowUnusedLabels": false,
		"pretty": true,
		"stripInternal": true
	},
	"exclude": [ "node_modules", "dist", "**/*.ngfactory.ts", "**/*.shim.ts", "**/*.spec.ts" ],
	"files": [ "AUTOGENERATED" ],
	"angularCompilerOptions": {
		"annotateForClosureCompiler": true,
		"flatModuleId": "AUTOGENERATED",
		"flatModuleOutFile": "AUTOGENERATED",
		"skipTemplateCodegen": true,
		"strictMetadataEmit": true,
		"fullTemplateTypeCheck": true,
		"preserveWhitespaces": false
	}
}

[deebloo]

the base url will be overwritten. the base url will be where your public_api.ts file is. so your path is probably something like "@scope/project-name/*": [ "../../lib/*" ]

[bilaldabet]

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

[alan-agius4]

Can you please create a small reproduction?

[bilaldabet]

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

[alan-agius4]

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 ***@***.***> 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 ***@***.*** <https://github.com/example> /example' ) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#519 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQv-WorR9OZgTkW1x60sVf1p1ZFPPDr8ks5uODsggaJpZM4Rl7KV> .

[bilaldabet]

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

thank you,

[alan-agius4]

From the screenshot I think you are trying to incorrectly import the modules. Can you share a reproduction? Also, are you setting up the secondary entrypoints as per documentation?

https://github.com/dherges/ng-packagr/blob/master/docs/secondary-entrypoints.md

[aksjer]

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"

[bilaldabet]

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,

[alan-agius4]

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

[dgroh]

related ? #1058

[FirstVertex]

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.

[tridattran]

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.

[alan-agius4]

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.

[vigie]

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.

[tonysamperi]

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

[fireflysemantics]

Currently writing libraries that are Angular consumable like:

https://www.npmjs.com/package/@fireflysemantics/slice
and
https://www.npmjs.com/package/@fireflysemantics/validator

And using paths make development a lot more pleasant. Paths for these projects is setup using this technique:

https://medium.com/@ole.ersoy/node-consumable-modules-with-typescript-paths-ed88a5f332fa

It would be really great if we could use paths for both Angular applications and angular libraries. Having this be symmetrical makes sense.

[abhidevmumbai]

Any solution on this?

[github-actions]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.
_{This action has been performed automatically by a bot.}