Angular-cli: ng serve removes /dist directory, but I would like to have it under version control

[stepanzarubin]

[email protected]

[grizzm0]

This was done on purpose in #4293. Any reason why you would want dist in VCS?

Without a build before committing the build would be out of sync with the current revision anyhow.

[stepanzarubin]

@grizzm0 because dist is synonym of an actual build, and it is, ng serve serves the actual code base, but not the build, build is done once per week, month, etc. and has nothing to do with a current working directory. Another synonym of a dist is release, a lot of packages/libraries put their releases under dist directory and have it under version control.

Also, having dist under VCS allows us to keep everything in one place.

[stepanzarubin]

ng serve should accomplish its own task => serve actual code. And suddenly it starts to remove files from the outside? this is weird, the other developer was confused, to get rid of a confusion it is enough to understand that there is nothing under dist directory when ng serve is running, README can be updated to clarify this.

At least, removing dist should not be a default behavior, can be achieved by specific configuration option or a command argument.

Thanks.

[grizzm0]

It was changed as alot of people thought ng serve would serve the dist folder if present.

@filipesilva You got any input on this?

[stepanzarubin]

@grizzm0 then, why to have a dist folder at all? what is a purpose of it? temporary folder for temporary content? let`s take a look at scenario:

1. I make build: ng build --env prod which will write it under dist folder
2. Then I run ng serve and my build is gone... wow

Why do I stop ng serve at all to make a build?

[grizzm0]

Build is part of my deploy flow. I guess that's how most people use it.

[stepanzarubin]

@grizzm0 what will happen if build was not successful? for any reason, build can output files successfully, but they may not work (e.g. local build is ok, but there is something wrong with prod one).

[stepanzarubin]

I believe each command should remove/update only files this command is working with. ng build can clean build directory, but not other command.

[grizzm0]

If tests fail during deploy the deploy will be cancelled. If it builds successfully but something is wrong I would either store x releases on the prod machine or rollback by checking out a previous tag and build from that.

[stepanzarubin]

The world is not perfect, tests does not cover everything perfectly, some people do not write tests.

[grizzm0]

You could still rollback by tag or keep releases on your prod server. :p

[filipesilva]

I'm sorry this change disrupted your workflow. We're not looking at changing it back though.

dist/ had, at best your last ng build and was never reflective of ng serve.

My recommendation for your particular case is to do make a build using the --output-path (-op) flag and keep that one under version control.

ng build --output-path=last-build/

[hinol]

My solution for this:

After update Jan 2017 noticed new problem. Command ng serve remove /dist dir.

Solution:

File: package.json (new command prod-build)

"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"prod-build": "ng build --output-path=last-build/ --env=prod",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e"
},
File: angular-cli.json (change ourDir)

"outDir": "/tmp/dist",

To build your prod version run: npm run prod-build

To serve: ng serve

In this configuration: ng server will create tmp dir, and your project directory will be clean, even when you commit changes without stop ng serve.

[lgellert]

Having the latest production build in /dist was part of my build process too. By setting up a command in package.json as @hinol suggested that sends it to a custom folder (/dist-prod/), I can live with it, minimal changes elsewhere.

My command is:
"build-prod": "ng build --prod --env=prod --output-path=dist-prod/" note the extra --prod flag, which does the uglifying and tree shaking.

[pljspahn]

Here because even when I'm building to another output path, that path gets wiped each time I build and I lose the .git folder.

Why can't it just spit the output to that folder instead of removing everything and then dumping the contents there?

[jakeNiemiec]

Build is part of my deploy flow. I guess that's how most people use it.

@grizzm0 I have seen the light. Turns out I wasn't giving this a fair chance. Having TravisCI build & publish my npm package is so much better than commiting /dist to VCS.

[JasonGoemaat]

This is SOOO wrong. 'ng serve' is deleting an entire directory's contents that might not even be your build output if you've changed its location. There is no documentation on this, deleting an entire directory seems to be a 'hidden feature' of the 'ng serve' command. In my experience having programs delete a directory without informing the user is a bad idea. At the very least there should be an output line when running 'ng serve' that says Deleting the contents of the dist directory...

[filipesilva]

I should mention that on 1.1.0-rc.0 there is a new --delete-output-path flag, defaulting to true. We introduced it both for Docker setups that link the dist directory, and for custom setups that use another build system to produce artifacts in dist.

[9ae8sdf76]

Hello. @filipesilva and/or @grizzm0, I'm a bit new to the front-end development and using Angular's cli. I've never done deployments before, so I'm curious why having a dist/ folder that's not empty is somehow a bad thing?

Also, isn't the suggestion of renaming the dist/ folder (i.e., last-build/) nothing more than lipstick on the proverbial pig? In other words, whatever the problem is with having a dist/ folder won't actually be solved, because you've simply renamed it.

The reason why it confuses me is because I was reading an article about creating angular modules for NPM, and it's rule of thumb is to build into the dist directory, and push to npm from there, so that only the necessary files get published. If this is not the correct workflow, would you have any documentation about the best-practice workflow developers should be using?

Thank you in advance!

[filipesilva]

@dohpaz42 while a dist/ folder contains build artifacts for both apps and libraries, they are used differently. For apps, the dist folder is often deployed, while for libraries it can be installed via the dependency manager or linked for live development.

There is no problem in having a non-empty dist/ per se, but due to it being a auto-generated folder in both cases, it's content is transient during development cycles. The build system deletes and recreates it's contents as needed.

Take for instance fingerprinting - the hash that gets appended during production builds. If dist/ wasn't deleted wholesale between builds, it would quickly accumulate a lot of past artifacts that are not used anymore. This also happens for any files in assets that you had at one point and removed since.

There are some advanced usecases where it is desirable to not delete the dist/ folder, such as symlinks for docker development or when multiple build systems are outputting to dist/, but those are the exceptions rather than the norm.

Angular CLI does not yet support libraries (https://github.com/angular/angular-cli/issues/1692), but you can find some temporary guidance in https://github.com/angular/angular-cli/issues/1692#issuecomment-285363067 and https://github.com/angular/angular-cli/issues/1692#issuecomment-301736484.

[severin2]

I realize that this is closed, but I keep ending up on this issue while searching for a while to make ng-cli clean everything inside of dist/ but not remove the folder. There's a definite use case for it.

In our case we are building the app with the angular cli and serving it with the nginx docker container. During development, we simply volume map the dist directory of our project to that container so we can see updates without starting the container.

Docker volume mapping strongly disagrees with removing the root volume mapped directory. And yeah we could map the next directory up and use docker trickery to ignore large folders like node_modules.

As another point of interest, we have a separate project where we added webpack manually to an old app, and we had to explicitly tell it to clean dist/* insead of dist/ to solve this problem.

[filipesilva]

@severin2 the --delete-output-path=false option was added for that specific scenario. See https://github.com/angular/angular-cli/wiki/build for details.

[jayoungers]

I believe ng serve --delete-output-path false is working for me.

One thing to note that while the flag is documented in the wiki for the build command, it's not documented for serve.

In my situation, once deployed the UI and API run under the same webserver. As part of the build I have a test to verify static content is being served with a no-cache header. That works fine on the build server, but locally I wasn't able to run the test since the dist folder was being removed on ng serve (npm postinstall will stub in a fake file specifically for this test; during the actual build that folder gets replaced)

[izy2nv]

@filipesilva I'm trying to integrate my angular 4 project in an already existing maven project. I understand the '/dist' folder has to be referenced in the 'target' dir of my maven project. How can this integration be done in this case since angular-cli deletes my dist folder?

[bastienJS]

@izy2nv Try ng serve --deleteOutputPath=false that worked for me prevention the deletion of my outDir value.

[figloalds]

I too got annoyed by that angular/cli screwover, but to me making a custom npm run build was even more convenient since I can use npm run build --prefix from parent folder (which holds many more projects and the actual dist folder), makes my workflow a bit more fluid.

[9ae8sdf76]

@felyperennan open a new ticket. this one is closed, and as such, it seems the devs stop caring about it.

[figloalds]

I'm not asking this to be changed, I think everyone already adapted to this by this point, I'm just adding how a custom npm script can be even more beneficial than having this particular behavior changed. But thanks anyways.

[johnking]

Just want to add my two cents here.

I am developing a desktop app with electron, so I need to keep the dist folder to make electron running, in the meantime, I can run ng server for angular component development.

ng serve --deleteOutputPath=false is good enough for my case.

thanks

[shoagraw]

it deleted some on my work in progress file and not able to find those files now, not even in recycle bin,
Any idea where these files will go after ng build deletes these.

[jakeNiemiec]

@shoagraw, they are deleted permanently from the filesystem: https://github.com/angular/angular-cli/blob/master/tools/publish/src/build.ts#L75

[hamdimefteh]

change /dist to other folder path !

[Terrafire123]

Running "ng build --output-path='../'" , instead of creating a directory in the parent named "dist", just deleted 12 hours of my work.

A little warning, or maybe an error message would have been nice.

Instead, AFTER my entire project was deleted, I got a cheery little message saying "Path must be a string. Received null"

[michaelb-01]

Has the delete-output-path flag been removed in Angular CLI 6.0.0?

[rsheptolut]

It also seems Angular CLI 6.0.0 stopped deleting the "dist" folder by default. Had to add rmdir .\\dist /S /Q && to my npm start script before ng serve, because oddly enough I've depended on the old behavior 🙂

[jakeNiemiec]

Looks like they learned that side-effects are bad (however well-intentioned):

Before: https://github.com/angular/angular-cli/pull/4293
Code: https://github.com/filipesilva/angular-cli/blob/4a653e2820539cf71faf51ac2e0e195c23a234bd/packages/angular-cli/tasks/serve.ts

After: https://github.com/angular/angular-cli/pull/9883
Code: https://github.com/angular/angular-cli/blob/bc56efa0535fe068b976fffaf3c2e570c967a333/packages/%40angular/cli/commands/serve.ts

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}