최근에 uglify-js를 사용하여 자바 스크립트를 압축하기 시작했습니다. 소스 맵은 디버깅을위한 훌륭한 기능이지만 자바 스크립트 압축의 이점 중 일부는 난독 화입니다.비밀번호로 보호 된 디렉토리에 JS 소스 맵 넣기
암호로 보호 된 디렉토리에 소스 맵을 넣으면 수동 관찰자가 JavaScript를 다시 사용할 수 없게됩니까? 그에게는 부작용이 있습니까?
브라우저가이 파일을 요청하는 방법과시기에 익숙하지 않습니다. 비밀번호 프롬프트 및 불편을 유발하는 사용자를 유도하고 싶지 않지만 공개적으로 볼 수 없기를 바랍니다.
음, Grunt를 사용하면 개발 환경에 따라 다른 루틴을 설정할 수 있습니다. 즉 당신은 dev에 유용한 Sass 주석을 발견 할 수 있지만 제작에 갈 때는 모든 주석을 제거해야합니다. 소스 맵과 동일합니다. 내가 뭘하고 싶은지는 사이트가 생방송되기 전에 모든 것이 제대로 작동하는지 확인하기 위해 축소 된 스크립트로 테스트하여 내 개발 환경을 가능한 한 프로덕션 환경에 가깝게 만드는 것입니다.
라이브 사이트를 디버깅하는 대신 버그 수정, 개선 등을 할 수있는 프로덕션 사이트의 로컬 복제본이 있어야합니다.
예, JavaScript를 가져 와서 다시 아름답게 만들 수는 있지만 처음에는 웹 사이트에 저장하지 않는 (압축되지 않은) 소스 파일이 필요하다고 생각합니다. 그들이 남겨 두어야 할 것은 1 문자 변수와 함수 이름을 가진 미적 JS입니다. 아무도 실질적으로 쓸모가 없습니다 :-)
시스템 관련 문제를 디버그하기 위해 사용자와 화면 공유하는 경우가 많습니다. 우리는 원격 컴퓨터에서 압축되지 않은 소스 파일을 사용할 수있게하는 것이 가장 이상적입니다. 액세스 제어의 일종을 찾고 필요할 때 얻을 수 있지만 최소한 조직 외부의 사람들을위한 원시적 인 보호 뒤에 있습니다. –
기본 인증은 아마 자바 스크립트가 파일 (즉, 모든 사용자)을 요청할 때 패스워드 프롬프트를 요구하기 때문에 아마도 그 다음에가는 길은 아니라고 생각합니다. 대신 서버 측 로직을 수행해야 할 수도 있습니다. 예를 들어 관리자로 로그인하면 압축되지 않은 소스에 액세스 할 수 있지만 재사용 가능한 강력한 크로스 브라우저 테스트 스위트 (Jasmine과 같은 것을 사용하는 경우) 프로덕션 코드를 디버깅 할 수 있어야합니다. 디버그는 로컬 테스트 스위트를 사용하여 로컬 복사본에서 수행해야합니다. :) – Ben
종종 브라우저 확장, 브라우저 설정, 악성 코드 또는 이전에 잡을 수없는 여러 가지 문제와 충돌하여 화면 공유 문제가 발생합니다. 우리의 다른 프로젝트 중 하나에서 우리는 unimified scripts serverside를 포함하도록 설정할 수있는 플래그를 가지고 있습니다. –