prevent ng build from overwriting source files

[netikras]

Okay, that one was scarry as hell. I am sooo lucky I pushed my project to GH before building ng sources prepared for prod....

What I did was opening .angular-cli.json and setting
"outDir": "../../",

as I wanted to store built files next to my project so that I could simply exclude project in gradle. Turns out that was a terrible mistake as ng build --prod decided to nuked my whole UI project for good. Yes sir it did. 10 days of work have been completely vanished from my harddrive. Good thing is that I did push it all to git before...

I would strongly suggest to add safety switches preventing self-destruction in the whole ng-cli project.

[filipesilva]

Heya, I'm really sorry about this happening. We do have such a safeguard but it seems to be broken:

https://github.com/angular/angular-cli/blob/master/packages/@angular/cli/tasks/build.ts#L24

We'll fix it and make sure it doesn't break again, it seems we didn't test this correctly.

[filipesilva]

Actually, on second thought you say you put the outdir in the parent directory for the project... we don't really cater for that case. Maybe we could error out if the outdir is any part of the parent dirs.

[netikras]

Just an idea... what about creating lock files (hidden, of course) in build dir, right next to the files built? And if the lock is missing - warn user that everything in that directory will be erased and ask for confirmation (providing FULL PATH to outDir, because these dot-dot-slash-repeat notations might be very tricky sometimes; also symlinks here do not make life any easier). Kind of initializing build directory... Next time user is building its sources ng-cli would look for lock file in outDir and if it's present - delete everything in that directory w/o asking for any confirmations, then recreate the lock and build the project. if lock file name is constant (or can be overriden in configurations at will) it would be easy to exclude it if built files are to be processed further (e.g. gradle).

Maybe I'm just paranoid after my experience, but I imagine someone might set outdir to /home/myuser/ and that would effectively destroy the user :) Also after my experience as Linux sysadmin I've learned that giving users an ability to remove anything is a very risky thing to do and mechanisms preventing the user from shooting its own feet must be in place :) Especially when that ability (to remove smth) is implicit...

Or just restrict to some directory inside the project root. But then there's less flexibility :?

Just chipping in my 2¢ :)