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

Webpack Rebuilds When Swap Files (*.swp, *.swo, *.swn, ...) Change #4593

Closed
frederikaalund opened this issue Feb 10, 2017 · 11 comments
Closed
Assignees

Comments

@frederikaalund
Copy link

frederikaalund commented Feb 10, 2017

OS?

Linux (Ubuntu 16.04)

Versions.

@angular/cli: 1.0.0-beta.31
node: 6.9.4
os: linux x64
@angular/common: 4.0.0-beta.7
@angular/compiler: 4.0.0-beta.7
@angular/core: 4.0.0-beta.7
@angular/forms: 4.0.0-beta.7
@angular/http: 4.0.0-beta.7
@angular/platform-browser: 4.0.0-beta.7
@angular/platform-browser-dynamic: 4.0.0-beta.7
@angular/router: 3.4.7
@angular/cli: 1.0.0-beta.31
@angular/compiler-cli: 2.4.7

Repro steps.

  1. Run ng serve
  2. Edit any source file in vim (or similar) but do not save
  3. Webpack recompiles even though you didn't save.
    1. This is most likely due to vim saving any edit to swap files (*.swp, *.swo, *.swn, ...). Webpack registers the change to the swap file and triggers the recompilation.

This seems unnecessary and slows down the workflow. When I actually do want to trigger an update, I save the file. However, now I have to wait for the previous (unnecessary) compilation of the swap files to finish before my actual changed files will be compiled again.

Also, webpack constantly recompiles in the background (due to vim saving to the swap files for every new line) which is a little distracting.

Can you configure webpack to ignore common swap files (*.swp, *.swo, *.swn, ...) or allow me—the user—to specify, which files to ignore?

I like @angular/cli. I like webpack. I like vim. Can there be peace?

@joshwiens
Copy link
Contributor

@frederikaalund - As a workaround, you could tell vim / neovim to store swap files somewhere else.

Something to the effect of ...

#vimrc

set dir=$HOME/.vim_tmp/swap
if !isdirectory(&dir) | call mkdir(&dir, 'p', 0700) | endif

This should send all of the .swp / .swn / .swo to whatever directory you define & create it if it doesn't exist. Not quite sure how tight you can make the permissions in vim, the above is what I use with neovim so you may need to tinker a bit.

That said, @frederikaalund is correct .swp$ and it's counterparts should be excluded for us *nix folks :)

@frederikaalund
Copy link
Author

@d3viant0ne Thanks for the workaround. I'm now using

set dir=$HOME/.vimtmp/swap//
if !isdirectory(&dir) | call mkdir(&dir, 'p', 0700) | endif

This is good for now. Though I'd still like to see this just work out of the box as part of @angular/cli.

@joshwiens
Copy link
Contributor

Agreed. It does the same thing if you open finder on macOS in a project directory.

@jeffjen
Copy link

jeffjen commented Mar 1, 2017

Can this be addressed? I was surprised by this behavior when the builder kicks off any time the swap file gets written.

@filipesilva
Copy link
Contributor

This seems to be at the core of https://webpack.github.io/docs/troubleshooting.html#file-saves-in-webstorm-don-t-trigger-the-watcher as well, right?

If webpack supports ignoring these changes we're happy to implement it.

@nwp90
Copy link

nwp90 commented Mar 24, 2017

No, I don't think it is related. The issue with saves not triggering rebuilds is caused by well-behaved editors being very careful to never lose data and hence not directly overwriting the file being edited (they mention it with Vim, and it is a potential issue with Emacs and other well-behaved editors as well).

The problem here is that some editors write other temporary files besides the one you're actually working on, and it seems that webpack is picking up changes in them too.

JFTR, Emacs checkpoint files (.#*) and backup files (*~) could do with being excluded as well.

@seevee
Copy link

seevee commented May 2, 2017

To my knowledge, webpack's default behavior is to only watch for files that meet the following criteria:

  • File is specifically imported or required by the entry point or one of its imports/requirements.
  • File name matches regex for the "test" value in any included loader config.

Here's a very basic webpack config I'm using for a react project. The dev server only rebuilds the project when the above conditions are satisfied.

I tried messing around with the webpack.config.js file generated by ng eject in an angular-cli project to figure out what the offending setting was, but I haven't made any real progress towards understanding the problem.

Maybe someone more well-versed in webpack can take a look?

@filipesilva filipesilva self-assigned this May 23, 2017
@shailesh
Copy link

@frederikaalund @d3viant0ne @filipesilva

Those are temporary files created by the vim editor. The .swp is created when a file is opened in the editor. The .swo is created if the file is edited and the .swp already exists. Edit it a third time and you get a .swn, and so on. When vim is closed, those files should go away. If vim crashes or is killed, they may be left behind. They are safe to ignore.

@frederikaalund
Copy link
Author

@shaileshgoogler Thank you for your input. However, we are all already aware of the purpose of the .sw* files. The issue at hand is how angular-cli treats these files.

@filipesilva
Copy link
Contributor

#7310 should have fixed this. It's released in 1.3.1/1.4.0-beta.1.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants