Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The best way to use this module fixing "@" and "deep" issue #25

Open
Yehonal opened this issue Jun 19, 2020 · 2 comments
Open

The best way to use this module fixing "@" and "deep" issue #25

Yehonal opened this issue Jun 19, 2020 · 2 comments

Comments

@Yehonal
Copy link

Yehonal commented Jun 19, 2020

Before using this package I was reading this article: https://gist.github.com/branneman/8048520 and then I came up with my "npm link solution": https://gist.github.com/branneman/8048520#gistcomment-3346781

But I've noticed that link-module-alias uses more or less the same approach and I managed to find a proper way to use it in every cases.

First of all stop to create tons of useless aliases, do it in the right way and create an alias that has exactly the same name of your package. In this way if you are using your package as a "final application" or as a dependency, the paths will be kept in both cases.

Second, do not use the "postinstall" script but the "prepare" script in this way: "prepare": "npx link-module-alias"

It will create the link only when you're running npm install inside the package folder (so won't do anything when your package is included as a dependency).

When your package is a dependency nodejs will resolve the paths automatically without the need of a symlink.

PLUS: if you still have issues with intellisense on your vscode, consider to add the "paths" option inside tsconfig.json that will point to your root directory.

I'm trying it in production and everything works fine

@mrsufgi
Copy link

mrsufgi commented Jul 1, 2020

First of all stop to create tons of useless aliases, do it in the right way and create an alias that has exactly the same name of your package. In this way if you are using your package as a "final application" or as a dependency, the paths will be kept in both cases.

This is very opinionated and I find myself giving aliases to folders I want to hide their long path, going with "same structure" is very limiting.

@Yehonal
Copy link
Author

Yehonal commented Jul 2, 2020

I think that the first goal of an alias module should be the possibility to solve the "relative paths hell"

About the long paths, personally I use a domain based folder structure under /src that most of the time doesn't exceed the 2 levels

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants