This deleted all my source files?

[OmgImAlexis]

So I used yarn as usual to add a new dependancy and from the looks of it all my source that was symlinked via node_modules was removed.

Lucky I had just committed and could use git to retrieve the files but this looks like a huge issue.

PING: @Rush

[OmgImAlexis]

I'm testing but I believe the pre-install script is what would have prevented this.

Maybe there should be more than a small message in the readme about it? Personally I'd suggest having the package check for the preinstall hook and add it unless there's a flag passed.

Something like --no-install?

[Rush]

So I used yarn as usual to add a new dependancy and from the looks of it all my source that was symlinked via node_modules was removed.

Wow, this sounds bad. Can you show me the structure of your project? Btw. just yesterday I discovered that it's possible to link subdirectories via a file: version specifier, is it the way of your project?

[Rush]

Maybe there should be more than a small message in the readme about it? Personally I'd suggest having the package check for the preinstall hook and add it unless there's a flag passed.

Can you elaborate? I am not sure I understand.

link-module-alias shouldn't at any circumstances remove actual source code - this needs to be fixed.

[OmgImAlexis]

Clone this repo and try the steps below. Not sure if this also happens with npm, just wanted to get this to you ASAP.

➜  delete-bug git:(master) rm -rf node_modules
➜  delete-bug git:(master) yarn
yarn install v1.12.3
warning package.json: No license field
warning No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...

$ link-module-alias
[####################] 20/20link-module-alias: @components -> ./components
✨  Done in 0.80s.
➜  delete-bug git:(master) node main.js
TEST_COMPONENT
➜  delete-bug git:(master) yarn add fuse.js
yarn add v1.12.3
warning package.json: No license field
warning No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...

warning No license field
success Saved 1 new dependency.
info Direct dependencies
└─ fuse.js@3.3.0
info All dependencies
└─ fuse.js@3.3.0
$ link-module-alias
link-module-alias: @components -> ./components
✨  Done in 0.82s.
➜  delete-bug git:(master) ✗ node main.js
file:///Users/xo/code/delete-bug/index.js:1
Error: Cannot find module '@components'
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:734:10)

[OmgImAlexis]

PING @Rush

[Rush]

@OmgImAlexis I ran your steps - very helpful! .. and it looks like it's a bug in yarn ... I'll investigate it further

[Rush]

@OmgImAlexis it's not a permanent solution but this would help avoid this particular issue:

   "scripts": {
     "preinstall": "which link-module-alias && link-module-alias clean || echo",
     "postinstall": "link-module-alias"
   }

[Rush]

@OmgImAlexis the upstream bug is #5709

I added a comment to that issue thread:
yarnpkg/yarn#5709 (comment)

[Rush]

@OmgImAlexis the thread seems to indicate that another workaround is not using @ in front of the aliased package name.

[josecarneiro]

This happened to me a few times in the last week and it took me a while to understand that using yarn with link-module-alias was the cause of the issue. I haven't been able to reproduce it consistently, it will just happen once in a while. @Rush Is this issue only fixable on yarn's side?

[OmgImAlexis]

@josecarneiro this patch does fix the issue.

#3 (comment)

[josecarneiro]

@josecarneiro this patch does fix the issue.

#3 (comment)

I added it to my package.json and haven't been able to reproduce the issue ever since, so it seems like a plausible solution until yarn solves the underlying problem.

Thank you @OmgImAlexis and @Rush!

[josecarneiro]

Well, it did happen again after running yarn upgrade, even with the fix. It appears that the upgrade command does not run the preinstall hook. Just a heads up for anyone who may be encountering the same issue.

[OmgImAlexis]

This looks related. Possibly a bug?

yarnpkg/yarn#2878

[Rush]

Is not using @ in the package name an option for you guys?

[OmgImAlexis]

@Rush I'd prefer if we could keep using it. Any chance @/ or # would work?

[josecarneiro]

I find that using ´@´ is one of the great appeals of this module. Wanting to keep consistency between my backend codebase and my webpack-built client side app is the reason I researched this topic and consequentially found ´link-module-alias´. Changing the alias is a possibility.

[shawncplus]

@Rush Having the preinstall hook do a link-module-alias clean fixes it for me when doing npm install. HOWEVER, npm update doesn't run the pre or post install hooks and will happily delete all of my files. I would usually dig in and help debug this but frankly after having this delete in progress work about 5 times now I'm a bit too pissed to be helpful. At the moment this project is completely useless if you can't use standard npm install and npm update commands without it deleting work.

[seanohue]

I want to add to @shawncplus 's comment that this does not seem to be yarn-related at all, since it deletes files in plain npm as well.

[jsardev]

Uh, I wasn't lucky enough to be aware of this issue before it deleted my day of work. I always forget to commit more frequently 😄

[jsardev]

At the moment this project is completely useless if you can't use standard npm install and npm update commands without it deleting work.

Have you tried naming your modules without the @ prefix?

[mfaheemakhtar]

"module-alias" was not working with the ESLint, so installed this one. This module worked perfectly.

And the moment I ran "yarn remove module-alias", everything in my project directory got deleted including .git

I just have just package.json and yarn.lock in directory (and the aliased directory @utils - empty).

My local commits got lost, several hours of work. Cool!

If this module has an issue, please add a big RED BOX on the npm page that this can potentially wipe the whole directory.

[Rush]

If this module has an issue, please add a big RED BOX on the npm page that this can potentially wipe the whole directory.

I am very sorry you've lost your work. :-( Can you share the setup that caused everything to disappear? We can then prevent doing this particular set up or at least warning against it.

[mfaheemakhtar]

@Rush, I don't have anything because everything got wiped. So, here is the explanation - no code.

1. Directories - constants, config, utils, db, api.
2. ESLint + Prettier config files. (.eslintrc, .prettierrc).
3. jsconfig.json to make aliases work for ESLint. Had added for "module-alias" but did not work.
4. And the configuration for the module as provided in the docs.

"_moduleAliases": {
"@api": "./api",
"@Constants": "./constants",
"@config": "./config",
"@db": "./db",
"@root": ".",
"@utils": "./utils"
}

ESLint was not working with "module-alias" package, so I installed this one (yours) and ESLint worked. Then the moment I ran yarn remove module-alias, everything got deleted (not even in the Trash).

I came to know that there is an issue with this module after it, if you could please add some warning with a link to this issue, it will be really helpful.

I'm ashamed that I had not pushed my work on GitHub.

BTW, I'm on Linux 18.04.2.

[seanohue]

There's no need to be ashamed @mfaheemakhtar, you're in good company based on this thread. I second the idea of a huge warning on the NPM page for this module, or even unpublishing it, until the issue is resolved.

[Rush]

@seanohue @mfaheemakhtar added the warning. Let me know if you guys think it's sufficient ...

[Rush]

I think I will add a warning at runtime that discourages the use of modules starting with @ .

[seanohue]

I think I will add a warning at runtime that discourages the use of modules starting with @ .

I think that's a good idea! Perhaps even throw an error if they use such an alias. I'm willing to make a PR that does this.

Thanks for being so responsive with this issue.

[jjangga0214]

@OmgImAlexis I don't want to make a useless debate, but let me just make it clean.

@misamisa23 already knows he or she should use other aliases rather than '@'.

Thus, @misamisa23 would be able to use link-module-alias without such an issue. That's it.

So, it just doesn't make sense to tell him/her not to use it.

[lwxbr]

Well, I had that problem yesterday! I lost my source files too. Luck of mine I have a repository in Bitbucket but I lost my .env that I will have to configure once again. It could be worse. I was warned but it doesn't justify the issue.

It happened when I tried to install the module moment-timezone. I work in Windows and that file shredding only happened when I ran yarn add moment-timezone in a Linux system (I don't know if it is relevant but is what it is).

Edit: It is clear that is not a Operating System Issue, i tried the same thing in Windows and it deleted even my .git folder.

Really, there's no way to prevent this?

We have the evidences, what we need to fix that issue for once and for all for the sake of the good operation of the npm modules? They should not be risky but safe. We need to investigate and fix!

[jsardev]

@lwxbr Please read the conversation. We know what's the root cause of this issue and it's how yarn and npm handles aliases in node_modules.

[lwxbr]

@sarneeh, and how you will fix it then? For me it is not clear that it is already solved. It is showing a warning that I should not use @ for alias and that's it. I'm using yarn 1.19.1 and link-module-alias 1.2.0, just update them will not solve the issue!

[jsardev]

@lwxbr As you can see this issue is not solved as it is in Open state. I won't fix it, because I don't have time for that and the workaround is enough for me. If you want to fix it, create a PR which solves yarnpkg/yarn#5709 😃 Again, please read the whole conversation before asking questions which already have been answered 😉

[lwxbr]

@sarneeh, thanks for explanation! I think that issue should be closed if it is a yarn issue. But the module should create a workaround, at least one thing to prevent the deletion of the modules (that is ugly).

The questions were answered? No, they aren't in the documentation of the project. That should be there, not here hidden in a issue not resolved.

[SARFEX]

i have same problem while npm install somenewmodule
npm 6.13.4, node 12.14.0, Windows 10

[Rush]

The questions were answered? No, they aren't in the documentation of the project. That should be there, not here hidden in a issue not resolved.

Agreed. Would you mind sending a PR to change the README file?

[OmgImAlexis]

A README update still doesn’t fix this issue though. This should be the default case.

This is still a danger to users that haven’t committed code. I lost a whole day worth at least a few times that’s hundred of dollars of wasted time.

[Rush]

Ok, let's put it to rest then. What is the proposed solution? For some reason people want to keep using @ despite the warning at the top of README: https://github.com/Rush/link-module-alias#if-you-use--in-your-linked-module-names-there-is-a-risk-this-module-will-cause-data-loss

Should the warning be larger? Should it be a prompt? I don't advise using @

[OmgImAlexis]

I'd suggest disabling the use of the issue causing code until they enable an option that clearly states what can happen. It shouldn't be so easy for this to happen.

[EvgeniyZ]

I'm experiencing the same problem even if I'm using # sign instead of @

package.json

"scripts": {
       ...
        "postinstall": "link-module-alias"
    },
"_moduleAliases": {
        "#pages": "./specs/pageObjects",
        "#features": "./specs/pageObjects/FeatureObjects",
        "#helpers": "./specs/helpers"
    },
"devDependencies": {
    ...
    "link-module-alias": "1.2.0",
}

When I'm doing npm install then files in these directories (./specs/pageObjects, ./specs/pageObjects/FeatureObjects and ./specs/helpers) are deleted.

EDIT:
I noticed that this happen only when I already had node_modules folder, so when I removed this folder and run npm install from scratch - it works fine, as expected. And after I did re-run npm install with node_modules - no data loss found. Maybe it will be helpful for someone

[hktr92]

I managed to reproduce this issue, even with this solution.

I can't provide a testing environment, because it's a project related to workplace.

So basically this project uses multiple themes (let's give them random names: classic, acme, supernova) and shares a common JS files in the build process.

• Themes are in {PROJECT_ROOT}app/themes directory, having assets/ and components/ subdirectories.
• The common assets are in {PROJECT_ROOT}core/assets/v1/js directory
• _moduleAlias value is: @sdk -> {PROJECT_ROOT}core/assets/v1/js in each theme (even in @sdk)
• executed command yarn remove some-useless-package in app/themes/supernova
• concurrently executed command yarn add some-cool-package in core/assets/v1/js

What happened:

• the second command failed (see yarn-error.log) as it couldn't find some module in @sdk
• the first command was executed successfully

I think that yarn remove some-useless-package triggered some delete command and removed the whole alias directory (luckily I had a FTP sync in place and managed to restore from there).

Sure, it's pretty rare to have yarn remove command, but anyway, I have updated the package.json to have following lines:

{
    "preinstall": "which link-module-alias && link-module-alias clean || echo",
    "preuninstall": "which link-module-alias && link-module-alias clean || echo",
    "preversion": "which link-module-alias && link-module-alias clean || echo",
    "postinstall": "link-module-alias",
    "postuninstall": "link-module-alias",
    "postversion": "link-module-alias",
}

I think this is bloated. Is there any alternative to this, which is cleaner?

[OmgImAlexis]

@pankajvaghela not sure that solves the issue. Where else would they go? If not in node_modules than how exactly is the node require system meant to find them?

[pankajvaghela]

yeah my bad, figured it, after commenting.

Maybe we can make symlinks say in folder A. make wrapper file to export everything from there and then have that symlinked to node_modules?
though that would work for single files or 1 level directories only

[OmgImAlexis]

The issue is intellisense and module resolution. The issue really needs to be fixed on the npm/yarn side.

[ninjz]

For any of y'all using Typescript. This article here gives a good solution for path aliases by configuring tsconfig.json

[zecka]

With typescript I solve it with this solution by using tsconfig-paths

[Papooch]

So, like many others, I did not read the issue fully and thought that it only affects yarn and not npm and also lost most of the source code. I use git and commit often so it was not a huge deal, but may I suggest that the example code be changed from using @ to use # or any other symbol instead? Clearly, using @ is not safe and it should be made clearer.

[songhanpoo]

I have the same error and also lost most of the src code. I'm using -> alternative for @. the bad news with an alternative symbol.

[jjangga0214]

@Rush What about letting the program print an error message and just exit when it finds @?

[kjbilliot]

I've had this just happen to me when using ~ as a prefix.
I was previously using @, but have since moved away from it after encountering the data loss issue, is there some kind of artifact left over somewhere that I should be deleting?

[lesimoes]

gosh, this package delete all my day work... This package need a serious update in readme file, please remove example with @ and put a big and clear text about this issue.

DO NOT USE @ IN ALIAS!

[Rush]

If anybody has a good idea how to update the README or code to avoid the issue please send a PR. I tried to add the warnings already

[OmgImAlexis]

Why not remove the ability to use it? That might be the best option here.