Less.js: bin / lessc를 사용하면 "경로가 문자열이어야합니다. 정의되지 않은 수신"이 발생합니다.

이것에 관한 어떤 업데이트?

예, 업데이트가 있습니까?
LTS 인 node @ 6 로 이동하고 싶지만이 문제가 해결 될 때까지 할 수 없습니다.

이것의 상태에 대해 궁금하십니까? 노드 6/7에서이 오류가 발생합니다.

이 오류도 발생합니다 ..
별도의 맵 파일로 저를 어떻게 컴파일 할 수 있습니까?
다음 명령을 사용하고 있습니다.
lessc --no-color test.less --source-map=test.css.map -source-map-url=test.css.map

@jhnns가 언급했듯이 출력에 대한 두 번째 매개 변수를 찾고있는 것으로 밝혀

lessc --source-map=test.less.map test.less>test.css

그러나 출력 파일을 파이프 대신 매개 변수로 추가하면 작동합니다.

lessc --source-map=test.less.map test.less ./test.css

도움이 되길 바랍니다 👍

즉, 적절한 수정은 "소스 맵 파일이 지정되었지만 출력 CSS가 지정되지 않은 경우 오류 발생"입니다. 맞습니까?
분명히 소스 맵이 특정 CSS 파일을 참조 해야 하기 때문에 출력 CSS가 지정되지 않은 적절한 소스 맵을 생성하는 (저속하지 않은) 방법이 없습니다. 즉, 다음 명령 줄은 의미가 없습니다.

lessc --source-map=test.less.map test.less
lessc --source-map=test.less.map test.less > test.css

아니요, 예전처럼 작동해야합니다-다음 두 명령 :

lessc --source-map=test.less.map test.less
lessc --source-map=test.less.map test.less > test.css

이것을 마지막 줄로 출력해야합니다 :

/*# sourceMappingURL=test.less.map */

CSS 출력 파일 이름은 전혀 관련이 없으며 맵에 대한 링크 만 중요합니다.

CSS 출력 파일 이름은 완전히 관련이 없습니다.

소스 맵에는 출력 CSS를 가리키는 file 필드가 있습니다 (최신 사양 개정에서는 선택 사항임을 알 수 있습니다).

어느 쪽이든, 제가 말할 수있는 한 문제는이 부분에 있습니다. 따라서 output 가 정의되지 않은 경우 css 출력 디렉토리를 어떤 디렉토리 (sourcemap dir?)로 바꾸면됩니다.
음, PR은 좋습니다 (개인적으로 저는 소스 맵을 사용하지 않으며 추가 테스트를 위해 이러한 변경으로 인해 어떤 옵션이 깨질 수 있는지 전혀 모릅니다).

배관과 함께 외부 소스 맵을 지원하는 것은 기능적 가치를 제공하지 않습니다. * nix 사용자에게 실제 출력 매개 변수를 지정하는 대신 파일에 파이핑하는 규칙 만 제공합니다.

외부 소스 맵을 생성 한 다음 출력 CSS를 추가 작업으로 파이프하는 것은 의미가 없습니다.

파이핑은 체인의 다음 단계에서 발생하는 추가 변경 또는 최종 단계에서 웹 서버 응용 프로그램에서 제공하기 위해 소비되는 CSS (및 소스 맵)를 의미합니다.

Less가 CSS 출력을 변경하면 Less가 생성 한 소스 맵이 무효화됩니다. 소스 맵을 다시 유효하게 만들려면 이러한 변경 사항을 다른 소스 맵으로 추적 한 다음 Less의 원래 출력과 병합하여 원래 .less 파일의 올바른 내용으로 매핑을 복원하는 복합 소스 맵을 만들어야합니다. .

파이프 작업 체인에 더 이상 존재하는 것은 파이프로 전송되지 않기 때문에 더 이상 외부 소스 맵에 대한 참조를 갖지 않습니다. 따라서이 작업을 수행 할 수 없으며 항상 깨진 소스 맵에 갇혀 있습니다.

그리고 물론; 체인의 마지막 단계가 컴파일 된 CSS와 소스 맵을 제공하는 것이라면 동일한 문제입니다. 지도에 대한 참조가 없습니다. (어쨌든 하나의 요청에 대한 응답으로 두 파일을 어떻게 제공 할 예정입니까? 소스 맵을 인라인하는 중입니까? 그렇다면 시작하기 위해 인라인 맵으로 less 파일을 컴파일하는 것은 어떻습니까?)

나는 생성 된 아티팩트가 깨지는 문제로만 이어질 수있는 작업 조합을 허용하지 않는 명확성과 사용자 지침 (예 : '성공의 구덩이에 빠지기')을 선호합니다.

배관과 함께 외부 소스 맵을 지원하는 것은 기능적 가치를 제공하지 않습니다. * nix 사용자에게 실제 출력 매개 변수를 지정하는 대신 파일에 파이핑하는 규칙 만 제공합니다.

동의합니다. 출력 파일 이름을 지정하려면 lessc 컴파일러에 대한 인수로 지정해야합니다.

즉, 배관은 과거에 문서화 되었습니까? 그렇지 않다면 그것은 논쟁의 여지가 있으며 현재 행동을 문서화 할 수 있습니다. 그렇다면 과거 및 현재 지원되지 않는 행동을 문서화해야합니다.

즉, 배관은 과거에 문서화 되었습니까?

파이핑은 stdout 또는 stderr과 같은 스트림을 리디렉션하여 작동합니다. lessc에 출력 파일 이름이 주어지지 않으면 stdout으로 출력됩니다. 그런 의미에서 배관은 항상 공식적으로 지원되었으며 계속해서 지원되어야합니다. 그렇지 않으면 파이프에 의존하여 파일을 css로 제공하는 데 필요한 서버 응용 프로그램에 적시에 컴파일 된 파일을 적게 전달하는 사람들을위한 건전한 사용 사례를 많이 깨뜨릴 것입니다.

소스 맵과 함께 파이핑을 사용하려는 경우에도 정상적인 방법으로 가능합니다.
인라인 소스 맵으로 만든 다음 파이프의 추가 처리 단계에 의존하여 인라인 맵을 디코딩해야합니다. 수정 사항을 병합하십시오. 해당 단계가 lessc 컴파일러에 의해 컴파일 된 CSS를 추가로 수정할 때마다 인라인 소스 맵으로 다시 적용하십시오.

그런 다음 성능을 위해 외부 소스 맵을 원할 경우, 즉 모든 방문자에게 전달되는 인라인 맵의 추가 바이트를 피하십시오. -파이프 라인의 마지막 단계는 인라인 소스 맵을 분리하고 css 파일과 맵 파일의 두 파일을 출력해야합니다.

외부 소스 맵을 생성 한 다음 출력 CSS를 추가 작업으로 파이프하는 것은 의미가 없습니다.

파이핑은 체인의 다음 단계에서 발생하는 추가 변경 또는 최종 단계에서 웹 서버 응용 프로그램에서 제공하기 위해 소비되는 CSS (및 소스 맵)를 의미합니다.

나는 인용 된 정서에 동의하지 않으며 주어진 파이프의 반대편에 무엇이 있는지 가정하는 것은 잘못된 것이라고 생각합니다. 파이프가 어딘가에 업로드되면 어떻게됩니까? 파이프가 결과 CSS를 제공하지만 클라이언트가 항상 소스 맵을 필요로하는 것은 아니라면 어떨까요?

--source-map-url 플래그가 구현 되었기 때문에이 사용 사례가 지원되어야한다고 생각합니다.

어쨌든 사용자는 특히 도움말 텍스트에서 플래그를 전달할 때 파악할 수없는 잡히지 않은 오류를 보지 않아야합니다.

이 문제에 의해 차단 된 후 2 센트.