webpack --watch não está compilando arquivos alterados

Tentei correr webpack --watche depois de editar meus arquivos JS, ele não dispara uma auto-recompilação.

Tentei reinstalar webpackusando, npm uninstallmas ainda não está funcionando.

Alguma ideia?

FYI: parece OS X pode ter uma pasta corrompidos e não mais send fsevents(que watchpack/ chokidarusos / Finder) para si e quaisquer pastas filho. Não posso ter certeza de que foi isso que aconteceu com você, mas foi muito frustrante para mim e para um colega.

Conseguimos renomear a pasta pai corrompida e, em seguida, assistir os eventos ocorreram imediatamente conforme o esperado. Veja esta postagem do blog para mais informações: http://feedback.livereload.com/knowledgebase/articles/86239-os-x-fsevents-bug-may-prevent-monitoring-of-certai

As correções recomendadas no link acima são:

• reiniciando o computador
• verificar o disco e reparar as permissões por meio do Utilitário de Disco
• adicionar a pasta à lista de privacidade do Spotlight (a lista de pastas a não indexar) e, em seguida, removê-la, forçando efetivamente uma reindexação
• renomear a pasta e, em seguida, possivelmente renomeá-la de volta
• recriar a pasta e mover o conteúdo antigo de volta para ela

Os dois primeiros não funcionaram para nós, não experimentamos a sugestão do Spotlight e a recriação não se mostrou necessária.

Conseguimos encontrar a pasta do problema raiz abrindo o Finder e criando arquivos em cada pasta pai sucessiva até que uma aparecesse imediatamente (já que o Finder também será prejudicado por esse bug). A pasta mais raiz que não é atualizada é a culpada. Simplesmente o colocamos mve mvvoltamos ao nome original, e então o observador funcionou.

Não tenho ideia do que causa a corrupção, mas estou feliz por ter uma solução.

Se o seu código não está sendo recompilado, tente aumentar o número de observadores (no Ubuntu):

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Fonte: https://webpack.github.io/docs/trouidere.html

Adicionar o seguinte código ao meu arquivo de configuração do webpack corrigiu o problema para mim, espero que isso ajude. Não se esqueça de ignorar sua pasta node_modules, pois isso prejudicaria o desempenho de HMR (Substituição de Módulo Quente):

watchOptions: {
  poll: true,
  ignored: /node_modules/
}

Eu tive esse problema ao trabalhar com o WebStorm.

Desativar configurações -> Configurações do sistema -> "gravação segura" resolveu para mim.

Encontrou a recomendação para fazer isso em: Solução de problemas do WebPack

Só para adicionar soluções possíveis: eu tinha minha pasta de projetos dentro de uma pasta do Dropbox, movê-la resolveu o problema para mim. (OS X)

A distinção entre maiúsculas e minúsculas era o meu problema. Minhas chamadas de código para require () tinham todos os nomes de caminho em minúsculas, MAS os diretórios na verdade tinham uma letra maiúscula. Renomei todos os meus diretórios para letras minúsculas e a visualização do webpack funcionou instantaneamente.

Um problema é que, se seus nomes de caminho não forem absolutos, coisas como essa acontecerão. Eu tinha acidentalmente definido resolve.rootcomo em ./vez de __dirnamee isso me fez perder muito tempo excluindo e recriando arquivos como os caras acima de mim.

Se mudar fs.inotify.max_user_watches como apontado por César ainda não funcionar, tente usar polling em vez de watchers nativos, criando seu script conforme mostrado nos documentos ou executando um pacote web com --watch --watch-pollopções.

Observe que se você executar o webpack em uma máquina virtual (Vagrant / Virtualbox) e alterar seus arquivos na plataforma host, as atualizações de arquivo na pasta compartilhada podem não acionar o inotify no Ubuntu. Isso fará com que as alterações não sejam coletadas pelo webpack.

ver: tíquete Virtualbox # 10660

No meu caso, editar e salvar o arquivo no convidado (no vi) acionou o webpack. Editando-o no host (em PhpStorm, Notepad ou qualquer outro aplicativo) dit NÃO acione o webpack o que quer que eu faça.

Eu resolvi isso usando vagrant-fsnotify .

Trabalhe para mim em Laravel Homestead

--watch --watch-poll

Atualizações: deletar todo o diretório e clonar git novamente do repo corrige meu problema.

Se estiver usando o Vim, você deve tentar definir backupcopy como sim, em vez do padrão automático. Caso contrário, o Vim às vezes renomeia o arquivo original e cria um novo, o que bagunça o webpack watch:

https://github.com/webpack/webpack/issues/781

Basta adicionar isso às configurações do vim se for o caso:

definir backupcopy = sim

Eu estava tendo o mesmo problema em um arquivo .vue. Quando o servidor reiniciou, tudo funcionou bem, mas no próximo salvamento ele não recompilou mais. O problema estava no caminho do arquivo de importação que tinha uma letra maiúscula. É muito difícil descobrir esse problema porque tudo funciona na reinicialização do servidor. Verifique o caso de seus caminhos.

Não estava recompilando para mim, mas então percebi / lembrei que o webpack observa o gráfico de dependência e não apenas uma pasta (ou arquivos). Com certeza, os arquivos que eu estava alterando ainda não faziam parte daquele gráfico.

Para mim, criar pastas e arquivos no VS Code era o problema. Para corrigir, reclonei meu repo e, desta vez, criei novas pastas e arquivos por meio da linha de comando em vez do código. Acho que o Code estava corrompendo os arquivos por algum motivo. Vi que o aplicativo acabou de ser atualizado, então talvez seja um novo bug.

Eu tive um problema semelhante, nem webpack ou rollup no modo de exibição ware capturando as alterações que fiz. Descobri que a culpa foi basicamente minha, pois estava alterando o módulo (arquivo .tsx) que ainda não foi importado para nenhum lugar do aplicativo (por exemplo, App.ts, que é o ponto de entrada) e esperava que as ferramentas de construção relatassem erros. feito lá.

A maneira como resolvi o problema foi encontrando um erro de capitalização em um caminho de importação. A pasta no sistema de arquivos tinha a primeira letra minúscula, o caminho de importação era maiúsculo. Tudo compilado bem, então este foi apenas um problema de inclusão do relógio do webpack.

Também tive esse problema dentro de uma VM VirtualBox (5.2.18) Ubuntu (18.04) usando Vagrant (2.1.15) com sincronização rsync. De repente, o primeiro build roda muito bem, mas o Webpack não leva as mudanças em consideração depois, mesmo com fs.inotify.max_user_watches=524288set. Adicionar a poll: trueconfiguração do Webpack também não ajudou.

Só vagrant-notify-forwarderfuncionou (o vagrant-fsnotify não funcionou, por algum motivo), mas a reconstrução aconteceu muito rápido depois de salvar o arquivo no host e suponho que o rsync não teve tempo suficiente para terminar sua tarefa (talvez devido à quantidade de diretórios sincronizados dentro do meu Vagrantfile?).

Finalmente fiz o relógio funcionar novamente, aumentando também o aggregateTimeoutna configuração do meu Webpack:

module.exports = {
  watch: true,
  watchOptions: {
    aggregateTimeout: 10000
  },
  ...
}

Se esta solução funcionar para você, tente diminuir esse valor novamente, caso contrário, você terá que esperar 10 segundos até que a compilação seja reiniciada cada vez que você clicar em salvar. O valor padrão é 300 ms .

Eu tenho o mesmo problema. E percebi que não está compilando porque minha pasta contém alguns caracteres (*). E usar o plug-in do observador antigo parece resolver o problema. Adicione esta linha ao seu arquivo de configuração do webpack.

plugins: [
    new webpack.OldWatchingPlugin()
  ]

Para mim, deletar node_modulese executar o npm install ou yarn novamente para instalar todos os pacotes resolveu o problema

Qual foi a causa no meu caso:

Parece que o valor de: max_user_watches in the /proc/sys/fs/inotify/max_user_watches está afetando o webpack

Para verificar o seu valor real

$cat /proc/sys/fs/inotify/max_user_watches
16384

16384 estava no meu caso e ainda não era suficiente.

Tentei diferentes tipos de soluções, como:

$ echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p

Mas parece que mesmo se eu alterasse o valor, quando reiniciasse meu PC ele voltaria ao padrão 16384.

SOLUÇÃO se você tiver sistema operacional Linux (no meu caso, tenho Manjaro):

Crie o arquivo:

sudo nano /etc/sysctl.d/90-override.conf

E preenchê-lo com:

fs.inotify.max_user_watches=200000

Parece que 200.000 é o suficiente para mim.

Depois de criar o arquivo e adicionar o valor, basta reiniciar o PC e você estará ok.

Uma solução fácil no MacOS é a seguinte:

Abra duas janelas de terminal no mesmo diretório em que reside seu projeto.

Na primeira janela do terminal, execute: webpack --watch

Na segunda janela do terminal, execute: webpack-dev-server

Eu tentei muitas soluções possíveis e esta parece ser a mais confiável

Solução possível: mudar o contexto para o diretório do aplicativo.

Todos os meus arquivos de configuração do webpack estão em uma subpasta:

components/
webpack/
 development.js
app.js

Em webpack/development.js, set context: path.join(__dirname, '../')resolveu meu problema.

Depois de tentar várias estratégias para corrigir esse problema, acabei desistindo, mas, enquanto resolvia outro problema, tentei novamente e de repente o --watchsinalizador finalmente estava funcionando.

Para ser honesto, não sei o que o fez funcionar especificamente, mas depois de realizar as seguintes etapas, ele simplesmente começou a funcionar:

1. Install most recent gcc version
$ sudo port install gcc48
$ sudo port select --set gcc mp-gcc48

2. Install most recent clang version
$ sudo port install clang-3.6
$ sudo port select --set clang mp-clang-3.6

3. Export variables holding the patch to C and C++ compiler
$ export CC=/opt/local/bin/clang
$ export CXX=/opt/local/bin/clang++

Pode ter acontecido que durante a instalação desses pacotes alguma dependência apenas adicionou a peça que faltava no quebra-cabeça, quem sabe ...

Espero que isso ajude alguém que está lutando para fazer funcionar.

Estou adicionando outra resposta porque acredito que esta é a melhor solução até agora. Estou usando todos os dias e é demais! Basta instalar esta biblioteca:

https://github.com/gajus/write-file-webpack-plugin

Descrição: força o programa webpack-dev-server a gravar arquivos de pacote no sistema de arquivos.

Como instalar :

npm install write-file-webpack-plugin --save-dev

Tente mudar --watchpara-d --watch

trabalhou para mim

Se isso acontecer de repente em seu projeto, isso pode resolver o problema.

Talvez de alguma forma os arquivos que estavam rastreando as alterações do seu projeto que o webpack procura tenham sido corrompidos. Você pode criá-los novamente apenas seguindo etapas simples.

1. saia do diretório do seu projeto. ($: cd ..)
2. mova seu projeto para um diretório diferente ($: mv {projectName} {newName})
3. vá para o novo diretório ($: cd {newName})
4. inicie o servidor e verifique se ele recarrega a cada mudança de arquivo (deve funcionar na maioria dos casos, porque agora o webpack cria novos arquivos para observar as mudanças)
5. sair do diretório ($: cd ..)
6. mova-o de volta para seu nome original ($: mv {newName} {projectNam}) Isso funcionou para mim ............

Eu me deparei com essa pergunta quando estava tendo um problema semelhante - parecia que o webpack não estava sendo agrupado novamente, mesmo ao executar webpack --config.

Eu até excluí bundle.js e a página da Web ainda estava exibindo como antes de minhas edições.

Para aqueles de vocês que têm este mesmo problema, eu finalmente fiz a opção 'cache vazio e recarregamento rígido' no Chrome (clique com o botão direito do mouse no botão recarregar com o devtools aberto) e funcionou

Eu encontrei o mesmo problema, tentei muitas coisas, finalmente, o Chrome Clear Browsing Data no Mac funcionou para mim.

Esses módulos foram instalados:

"sincronização do navegador": "^ 2.26.7",

"browser-sync-webpack-plugin": "^ 2.2.2",

"webpack": "^ 4.41.2",

"webpack-cli": "^ 3.3.9"

O problema estava na distinção entre os arquivos .js e .ts. Por quê ?

Na construção do projeto, o Visual Studio compila os arquivos typescript em .js e .js.map. Isso é totalmente desnecessário, porque o webpack também lida com arquivos typescript (com o awesome-typescript-loader). Ao editar arquivos .tsx de componentes no Visual Studio Code ou com a opção compileOnSave desativada em tsconfig.json, o arquivo ts editado não é recompilado e meu webpack estava processando um arquivo .js incomum.

A solução foi desabilitar a compilação de arquivos typescript no Visual Studio na construção do projeto. Adicionar

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

em PropertyGroup do seu .csproj.