* 전혀 기술적인 이야기가 아닙니다.
너무 어리석은 에러에 장시간 괴롭혀 버렸기 때문에 계명에 정리하는 것입니다.

배경

이 기사 을 참고로 해서 개발중의 Rails 어플리케이션에 Docker를 도입하고 있던 곳, docker-compose build중에 다음과 같은 에러가 나왔다.



yarn packages가 오래되었습니다! 라는 오류 메시지. 이로 인해 잘 일어나지 않는 상황이 이어진다.
이쪽의 대처에 (매우 낭비로) 장시간을 소비해 버렸으므로, 반성도 담아 대처법을 기재해 두는 것.

해결책

오류 메시지의 하단에 주목하면, change 'check_yarn_integrity' to 'false' in your webpacker config file과 제대로 기재되어 있다(정중하게 패스까지)

그래서 말했듯이 config/webpacker.yml에 있는 check_yarn_integrity를 ​​false로 해주면 된다. (오류 메시지로 검색했을 때이 솔루션은 매우 히트했습니다)

그럼 왜 함정에 빠졌는지



여기 webpacker.yml의 실제 파일입니다. 9행을 보았을 때 이미 false가 아닌가? 되고, 여기에서 괴로워하게 된다.

이 솔루션을 작성하는 사람들 중 일부는 check_yarn_integrity = false로 해결합니다! 라고 써 있거나 했기 때문에, 그대로 기재해 보통으로 syntax error가 일어나거나.
docker-compose build 와 down을 반복하는 중에 과거의 컨테이너가 나빠져 다른 에러가 일어나거나, 게다가 도중부터 build가 아니고 마음대로 up으로 했었기 때문에 전혀 일어나지 않거나
(아마도 이 에러, build로 하고 있으면 build 자체는 할 수 있다. 그 후의 db 작성시에 에러가 일어나는 것.
나는 도중부터 마음대로 up으로 하고 있던 것을 깨닫지 못하고, 아까는 일어서는 했는데! ? ? 그리고 더욱 혼란스러웠다. 바보와. )

그런 이렇게 괴로워하는 가운데, 매우 부끄러운 실수를 깨닫는다.



이 이미지는 방금전의 webpacker.yml을 한 스크롤한 것이다.

56번째 줄에 녀석이 또

그래, development 환경의 기재가 아래에 기재되어 있어 거기서 check_yarn_integrity 가 true 로 설정되어 있었던 것이다 (이미지에서는 false 로 수정됨)
단지 그것만이었던 것이다. 그냥 그냥. . . .

결론

오류 메시지는 자신보다 훨씬 믿을 수 있습니다. 제대로 지정된 파일은 제대로 읽어 봅시다.
그렇다면 Command + F라고도 사용합시다.

docker 엉망진창 중에서 조작 익숙한 것만은 아직 좋았다····

＊초학자 때문에 뭔가 있으면 지적해 주시면 기쁩니다.