-
Notifications
You must be signed in to change notification settings - Fork 12k
ng serve removes /dist directory, but I would like to have it under version control #4366
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
Comments
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. |
@grizzm0 because dist is synonym of an actual build, and it is, Also, having dist under VCS allows us to keep everything in one place. |
At least, removing dist should not be a default behavior, can be achieved by specific configuration option or a command argument. Thanks. |
It was changed as alot of people thought ng serve would serve the dist folder if present. @filipesilva You got any input on this? |
@grizzm0 then, why to have a
Why do I stop |
Build is part of my deploy flow. I guess that's how most people use it. |
@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). |
I believe each command should remove/update only files this command is working with. |
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. |
The world is not perfect, tests does not cover everything perfectly, some people do not write tests. |
You could still rollback by tag or keep releases on your prod server. :p |
I'm sorry this change disrupted your workflow. We're not looking at changing it back though.
My recommendation for your particular case is to do make a build using the
|
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": { "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. |
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: |
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? |
@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. |
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 |
I should mention that on |
Address concerns in angular#4366, angular#6375.
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 Also, isn't the suggestion of renaming the 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! |
@dohpaz42 while a There is no problem in having a non-empty Take for instance fingerprinting - the hash that gets appended during production builds. If There are some advanced usecases where it is desirable to not delete the Angular CLI does not yet support libraries (#1692), but you can find some temporary guidance in #1692 (comment) and #1692 (comment). |
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. |
@severin2 the |
I believe 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 |
@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? |
@izy2nv Try |
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. |
@felyperennan open a new ticket. this one is closed, and as such, it seems the devs stop caring about it. |
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. |
Just want to add my two cents here. I am developing a desktop app with
thanks |
it deleted some on my work in progress file and not able to find those files now, not even in recycle bin, |
@shoagraw, they are deleted permanently from the filesystem: https://github.com/angular/angular-cli/blob/master/tools/publish/src/build.ts#L75 |
change /dist to other folder path ! |
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" |
Address concerns in angular#4366, angular#6375.
Has the delete-output-path flag been removed in Angular CLI 6.0.0? |
It also seems Angular CLI 6.0.0 stopped deleting the "dist" folder by default. Had to add |
Looks like they learned that side-effects are bad (however well-intentioned): Before: #4293 After: #9883 |
Previously, we run the PWA score tests before unit/e2e tests, because the latter would destroy the `dist/` directory required by the former. Since cli@6, unit/e2e tests no longer detroy the `dist/` directory, so it is now safe to run the unit/e2e tests first. This is preferrable, since they are conceptually lower-level and any error messages (in case of breakage) are more specific/actionable. Related discussion about cli behavior: angular/angular-cli#4366
Previously, we run the PWA score tests before unit/e2e tests, because the latter would destroy the `dist/` directory required by the former. Since cli@6, unit/e2e tests no longer detroy the `dist/` directory, so it is now safe to run the unit/e2e tests first. This is preferrable, since they are conceptually lower-level and any error messages (in case of breakage) are more specific/actionable. Related discussion about cli behavior: - angular/angular-cli#4366 - angular/angular-cli#14701
Previously, we run the PWA score tests before unit/e2e tests, because the latter would destroy the `dist/` directory required by the former. Since cli@6, unit/e2e tests no longer detroy the `dist/` directory, so it is now safe to run the unit/e2e tests first. This is preferrable, since they are conceptually lower-level and any error messages (in case of breakage) are more specific/actionable. Related discussion about cli behavior: - angular/angular-cli#4366 - angular/angular-cli#14701
Previously, we run the PWA score tests before unit/e2e tests, because the latter would destroy the `dist/` directory required by the former. Since cli@6, unit/e2e tests no longer detroy the `dist/` directory, so it is now safe to run the unit/e2e tests first. This is preferrable, since they are conceptually lower-level and any error messages (in case of breakage) are more specific/actionable. Related discussion about cli behavior: - angular/angular-cli#4366 - angular/angular-cli#14701
Previously, we run the PWA score tests before unit/e2e tests, because the latter would destroy the `dist/` directory required by the former. Since cli@6, unit/e2e tests no longer detroy the `dist/` directory, so it is now safe to run the unit/e2e tests first. This is preferrable, since they are conceptually lower-level and any error messages (in case of breakage) are more specific/actionable. Related discussion about cli behavior: - angular/angular-cli#4366 - angular/angular-cli#14701
Previously, we run the PWA score tests before unit/e2e tests, because the latter would destroy the `dist/` directory required by the former. Since cli@6, unit/e2e tests no longer detroy the `dist/` directory, so it is now safe to run the unit/e2e tests first. This is preferrable, since they are conceptually lower-level and any error messages (in case of breakage) are more specific/actionable. Related discussion about cli behavior: - angular/angular-cli#4366 - angular/angular-cli#14701 PR Close #31047
Previously, we run the PWA score tests before unit/e2e tests, because the latter would destroy the `dist/` directory required by the former. Since cli@6, unit/e2e tests no longer detroy the `dist/` directory, so it is now safe to run the unit/e2e tests first. This is preferrable, since they are conceptually lower-level and any error messages (in case of breakage) are more specific/actionable. Related discussion about cli behavior: - angular/angular-cli#4366 - angular/angular-cli#14701 PR Close #31047
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
[email protected]
The text was updated successfully, but these errors were encountered: