Less.js: @import를 여러 번 수행할 때 중복된 속성(중첩된 @import)

문제는 파일을 두 번 가져오는 것인데, 이것이 믹스인의 올바른 동작이라고 생각합니다.

파일을 두 번 가져와야 한다고 생각하십니까? 그렇지 않은 경우 상대 URL도 고려해야 합니다. 예를 들어

// in main.less
<strong i="6">@import</strong>: imports/import1.less;
<strong i="7">@import</strong>: imports/import2.less;

// in imports/import1.less
<strong i="8">@import</strong>: import2.less; // don't import this
<strong i="9">@import</strong>: imports/import2.less; // do import this

흠, 파일이 다른 파일과 같은지 확인하는 더 쉬운 방법이 있는지 궁금합니다. 헤더에 무언가가 있을 수 있습니다.

파일 크기는 값싼 지표이며 주어진 소스 파일 세트에서 고유할 가능성이 큽니다. 그러나 동일한 크기의 파일이 2개 있는 것은 _가능_합니다.

마찬가지로 날짜가 수정되었습니다.

서버가 ETag 헤더를 설정하면 그것을 사용할 수 있습니다/사용해야 합니다.

캐싱할 때 파일 내용의 MD5 해시를 키로 사용하지만 개인적으로 그건 무리라고 생각합니다.

흠, 네 문제는 자바 스크립트에 기본 MD5가 없다는 것입니다. 그렇지 않으면 그것을 사용할 것입니다.
ETag가 이상적이지만 일부 서버는 설정하지 않습니다. 나는 이것에 대해 생각해야합니다.

파일을 두 번 가져오면 안 된다는 데 동의하는 것 같습니다. 그러나 항상 사실입니까? (즉, 범위의 도움으로 mixim으로 가져오기가 괜찮을 수 있습니다. 클라우드 헤드는 이것에 대해 나보다 더 잘 대답할 수 있습니다).

많은 언어에서 이미 이 문제를 다양한 방식으로 해결했습니다.

• C -> #ifndef / #define / #endif
• PHP -> include_once()

"C 방식"은 구현하기가 조금 더 어려울 수 있지만 조건문은 다른 훌륭한 가능성을 제공할 수 있습니다.

"PHP 방식"이 선택되면 파일을 구별하는 방식을 선택해야 합니다. 절대 URL은 좋은 선택인 것 같습니다(직접 또는 document.location + 상대 URL을 통해 선택) - HTTP 요청을 사용하지 않기 때문에 크기 / 길이 / MD5보다 낫다고 생각합니다.
그러나 충분하지 않을 수 있습니다. 각 URL은 단일 파일에 매핑되지만 각 파일은 여러 URL에 매핑될 수 있습니다. 이러한 경우 새 키워드 @<strong i="16">@name</strong>: <unique name> 도입하면 도움이 될 수 있습니다.

@import_once 알고리즘은 다음과 같습니다. 절대 URL을 아직 가져오지 않은 경우 파일을 가져오고 @ @name 이 이미 가져온 상태인지 확인하고 파일을 가져오지 않은 경우 확인합니다.

나는 동의한다. 단일 요청의 컨텍스트 내에서 리소스가 변경되지 않는다고 가정할 수 있어야 합니다. 따라서 절대 URL은 충분해야 합니다.

파일 변경 사항을 확인하는 것은 또 다른 문제입니다.

이것이 원래 @import가 작동하는 방식이기 때문에 @import import를 여러 번 유지해야 한다고 생각합니다.

나는 @vicb 의 PHP와 같은 솔루션을 좋아하지만 @import_once 대신 'comment'에서 더 나은 것을 좋아하므로 여전히 원래 CSS 구문과 호환됩니다.

.less 파일 상단에 다음과 같이 추가할 수 있습니까?
/_! 필요:url (./abc.less)_/

저도 이 문제를 겪고 있습니다. 내 프로젝트에는 단일 .css 파일로 컴파일되는 LESS 파일 계층이 있습니다. 여러 파일에 포함된 하나의 유틸리티 LESS 파일이 있으며, 결과적으로 모든 믹스인은 해당 유틸리티 파일을 가져온 횟수만큼 복제됩니다.

@import_once 또는 아마도 @import : Once url('url'); 이 문제를 해결할 것입니다.

우리는 프로젝트에서 @NielsJanssen 과 같은 문제에 직면해 있습니다. 이 문제가 언제 수정될지 알 수

또한이 문제가 발생합니다. 누구든지 해결책을 알아내셨습니까?

여기에 같은 문제가 있습니다. 간단한 솔루션을 찾을 수 없었고 두 번 가져오지 않도록 가져오기를 다시 정렬했습니다.

node.js를 사용하는 경우 Stylus를 확인하는 것이 좋습니다. 나는 잠시 동안 LESS를 사용하다가 완전히 개발되지 않은 것에 좌절하고 SASS 로 전환한 다음 마침내 Stylus로 전환했습니다. 기능을 제대로 구현하고 구문은 선택 사항이며(저는 중간 방식을 사용합니다) 매우 강력하며 TJ는 정말 반응이 빠른 개발자입니다.

node.js를 사용하지 않는 경우에도 스타일러스를 루비와 함께 사용하고 컴퓨터에서 컴파일할 수 있습니다. 어떤 이유로든 Stylus가 마음에 들지 않는다면 SASS/SCSS도 좋은 대안이며 동일한 방식으로 수행할 수 있습니다.

긴 이야기 요약: LESS는 장기적으로 좋지 않습니다.

아주 나쁜 태도 남자.

여기에 해당 bs를 게시할 필요는 없습니다. 우편이나 이와 유사한 방법으로 보낼 수 있습니다. 무료로 사용할 수 있는 것에 대해 "정말 반응이 빠른 개발자"를 원하는 것과 같은 높은 기준을 가질 수 없습니다.

절대적으로하지.

나는 LESS를 처음 찾았을 때 그 조언을 좋아했을 것이므로 익숙해지고 결국 떠날 때 그것으로 전환하는 데 몇 주를 낭비하지 않았습니다. 닫힌 문제보다 미해결 문제가 더 많고 대부분이 응답되지 않았기 때문에 내가 먼저 그것을 알아차렸어야 했음을 인정합니다.

내가 가질 수 있고 가질 수 없는 기준이 아닙니다. 더 나은 대안이 있을 때 사람들에게 경고를 제공하는 것입니다.

그래서 나는 내 "BS"를 지키고 사람들이 경고가 도움이되기를 바랍니다.

@ianstormtailor : 프로젝트가 "장기적으로는 좋지 않다"고 말하는 것은 약간 히스테리적입니다.

이것도 같은 문제가 있습니다.

푸.리스

<strong i="7">@import</strong> "bar.less";
<strong i="8">@import</strong> "baz.less";

바.리스

<strong i="12">@import</strong> "mixins.less";
.bar {
  .mixer
}

바즈.리스

<strong i="16">@import</strong> "mixins.less";
.baz {
  .mixer
}

mixins.less

.mixer {
  color: 000;
  border: 2px solid #fff;
}

$ lessc foo.less
.mixer {
  color: 000;
  border: 2px solid #fff;
}
.bar {
  color: 000;
  border: 2px solid #fff;
  color: 000;
  border: 2px solid #fff;
}
.mixer {
  color: 000;
  border: 2px solid #fff;
}
.baz {
  color: 000;
  border: 2px solid #fff;
  color: 000;
  border: 2px solid #fff;
}

나는 이전에 이 토론에 참여하지 않았지만 지금은 동일한 문제에 직면해 있습니다 ... @ianstormtaylor 가 전혀 히스테리

@cloudhead 는 내가 하는 모든 의견을 대부분 무시한다는 인상을

모든 가져오기가 포함된 main.less 파일이 _가능_합니다. 예제는 트위터 부트스트랩 을 참조하십시오(메인 파일은 bootstrap.less ).

내가 (외부 라이브러리에서) 가져오는 적은 파일 중 일부는 독립 실행형으로 컴파일할 수 있도록 작성되어 각각에 공통 variables.less 되어 있고 내가 보고 있는 문제는 각 파일을 가져오기 때문에 발생합니다. 적은 수의 파일을 하나의 메인 파일로 만든 다음 해당 파일을 컴파일하면 믹스인이 포함되는 횟수만큼 각 믹스인이 적용됩니다(외부 라이브러리에서 포함하는 모든 파일에 대해 한 번).

당신이 맞아요 - 당신이 제안하고 난 내가 완벽하게 제어 할 수 있지만 그 코드에서 같은 일을하고 _am_처럼 내가 뭔가를 할 _could_ 하지 않습니다 평균 모두가 그런 식으로 작업을 수행합니다.

또한 해결 방법(타사 라이브러리를 사용하지 않는 경우 _only_)은 이것이 버그라는 것을 변경하지 않습니다. 덜 사용하여 문제를 해결하는 방법에 상당히 익숙해졌지만 이와 같은 버그가 거의 18개월 동안 열려 있다는 사실이 답답합니다. ( @wlangstroth 나는 그것이 _당신의_ 잘못이 아니라는 것을 깨달았습니다)

관심 있는 사람을 위해 #431에 대한 댓글에 붙여넣은 무차별 대입 수정( @vicb 의 테스트에 대해 테스트되지 않았지만 작동해야 함)이 있습니다. 시간이 좀 더 있으면 더 나은 솔루션을 찾으려고 노력하겠습니다.

같은 문제가

또한 이 문제가 있었지만 내 믹스인 라이브러리를 bootstrap.less로 가져와서 수정했습니다. 후속 가져오기에서 액세스할 수 있다는 것을 몰랐지만 이해가 됩니다.

fyi #431은 이 문제를 해결하는 풀 리퀘스트입니다.

@cloudhead 이에 대한 수정 사항을 적용할 수

같은 문제 :-(

이 문제로 어려움을 겪고 있는 사람에게 제안하기 위해 Alexis가 Twitter에 메시지를 게시하는 것이 좋습니다. Alexis는 이전에 여러 티켓에서 모든 문제를 모니터링할 수 없으며 심각성을 알게 된 경우에만 수정한다고 말했습니다. 나는 이것이 심각한 문제라고 생각하지만 Twitter에서 Alexis의 관심을 끌 수는 없었습니다.

어쩌면 다른 누군가가 더 운이 좋을 수도 있습니다.

트위터: https://twitter.com/#!/cloudhead

그리고 이 문제에 대한 링크를 드롭 하세요 :

@cloudhead 적절 모두가 그것을 사용하지 않도록 할 더 많은 이유는 그 다음이 프로젝트의 문제를 모니터링 할 수없는 경우 @Kalyse. 사람들은 그가 문제의 백로그를 관리하는 데 도움을 줄 다른 사람을 지명해야 한다고 제안했지만 다시 응답이 없었습니다.

내가 이슈에서 언급했을 때 이미 알림을 받을 수 있는 사람의 관심을 끌기 위해 트위터를 사용해야 하는 이유는 무엇입니까? @cloudhead 가 2년 동안 공개된 문제에 응답할 수 없다는 것은 부끄러운 일이라고 생각합니다. 그는 최소한 자신이 신뢰하는 두 사람을 찾아 미해결 문제의 백로그를 통해 작업을 시작하도록 할 수 있습니다. 그들은 적어도 중복을 닫고 그를 위해 미해결 문제의 수를 줄이는 데 도움을 줄 수 있습니다.

github 알림 시스템은 완전히 쓸모가 없습니다. 하루에 약 70-100개의 알림을 받기 때문에 그냥 무시하는 것을 선호합니다.

이거 조사해볼게..

자, @import-once 지시문을 추가했습니다. 경로가 일치하는지 확인하기만 하므로 매우 기초적이지만 대부분의 사용 사례를 다루어야 합니다.

@cloudhead 이 문제를 해결해

저는 개인적으로 pull 요청이 고려되지 않은 경우에도 이 프로젝트가 Github에 있는 이유 또는 문제가 무시되는 경우에도 이슈 트래커가 실행되는 이유를 개인적으로 이해하지 못합니다.

쉬운 사람들! 한 사람이 이렇게 인기 있는 프로젝트를 가지고 있다면 그들은 같은 배를 타고 있을 것입니다. @cloudhead 는 훌륭한 일을

사람들은 때때로 몇 년 전에 많은 문제를 해결했습니다. 응답이 없는 74개의 미해결 pull 요청 중 하나를 확인하십시오. 예를 들어 이 문제에는 2년 전으로 거슬러 올라가는 많은 속임수가 있습니다(예: #324 #71). 다음은 이 문제를 아주 간단하게 해결할 수 있는 풀 리퀘스트입니다. https://github.com/cloudhead/less.js/pull/431 커미터가 피드백을 요청했지만 묵묵부답이었지만 결국 포기했습니다.

@cloudhead - Alexis, 이것은 파손에 빠지기에는 너무 훌륭한 프로젝트입니다. 사람들이 위에서 언급한 종류를 볼 때 프로젝트가 신뢰할 수 없거나 신뢰할 수 없다는 인상을 줍니다. 그리고 그것은 불필요합니다! github의 마법은 훌륭한 코드를 작성하고 프로젝트에 참여하는 데 관심이 있는 사람들을 쉽게 찾을 수 있다는 것입니다. 문제를 조정하고 요청을 끌어오는 데 도움이 되는지 좋은 사람들에게 물어보세요.

우리 모두는 당신의 일을 사랑합니다. 커뮤니티는 도움을 원합니다. 도와드리겠습니다!

@jeremyricketts 좋은 지적입니다.

@jeremyricketts에 동의합니다. 제가 일하는 회사에서 이

@cloudhead @import-once 지시문이 작동하지 않는 것 같습니다. 이것이 제 테스트 사례입니다.

// a.less
.gain-bfc() {
  overflow: hidden;
  *zoom: 1;
}

// b.less
@import-once "a.less";

// c.less
@import-once "a.less";
@import-once "b.less";

div {
  .gain-bfc();
}

c.less 컴파일 후 예상 결과는 다음과 같아야 합니다.

div {
  overflow: hidden;
  *zoom: 1;
}

하지만 나는 중복된 속성을 얻었다

div {
  overflow: hidden;
  *zoom: 1;
  overflow: hidden;
  *zoom: 1;
}

+1 제레미리케츠

누구나 한 단계 올라가고 싶어 - https://twitter.com/#!/neonstalwart/status/183247994072735744

실제 프로그래밍을 잘하는 사람이 필요합니다. 내 세상은 PSD, 연필과 종이, html CSS와 가벼운 jQuery 작업입니다.

문제를 분류하고 pull 요청을 하는 데만 몇 사람이 필요합니다.
중복을 제거하고 버그에 대한 테스트 사례가 있는지 확인하십시오.
최소한 그 일을 돕기 위해 자원하여
작은 버그도 닫습니다.
2012년 3월 23일 오후 1시 28분, "Jeremy Ricketts" <
답장@reply.github.com>
썼다:

실제 프로그래밍을 잘하는 사람이 필요합니다. 내 세상은 PSD,
연필과 종이, html CSS와 가벼운 jQuery가 작동합니다.

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/cloudhead/less.js/issues/49#issuecomment -4667283

@cloudhead 이것 에 대한 좋은 해결책이 생각 얼마전 에

기본적으로 현재 속성과 동일한 값을 가진 기존 규칙이 있는 경우 규칙을 선택기에 추가해서는 안 됩니다. 배경의 경우 브라우저마다 다르게 처리되므로 여러 가지 다른 배경을 추가할 수 있으므로 속성 값도 확인해야 합니다.

이 솔루션 @cloudhead에 대해 어떻게 생각하세요?
앞으로 나아갈 것 같습니까?

이것을 수정하지 않는다는 것은 다음을 의미합니다.

1) 파일이 필요한 것보다 큽니다.
2) 믹스인도 포함하는 추가 파일을 포함할 때마다 해당 믹스인의 값을 다시 추가하기 때문에 CSS를 여러 파일에 퍼뜨리고 로트를 가져오는 것은 바람직하지 않습니다. 나는 아마도 80개의 lessCSS 스타일을 가지고 있으며, 이것은 내가 .background() 그라디언트 믹싱을 할 때 각 선택기에 대해 80 * 6개의 추가 스타일을 생성한다는 것을 의미합니다. (6은 모든 다른 브라우저를 지원합니다).
3) 또한 페이지 렌더링 속도가 느려집니다. 추가 스타일로 인해 초당 그리기/새로 고침이 극적으로 떨어집니다.

생각 @cloudhead ?
건배.

@cloudhead 최신 커밋에서 이 문제에 대한 pull 요청을 하면 병합을 볼 건가요?

수정 사항은 다음과 같습니다. https://github.com/cloudhead/less.js/commit/cb789334233e377bd91a17d3118a0424ad167929

@Kalyse 저에게 이메일을 보내주시겠습니까? [email protected]

건배

pull 요청을 승인할 수 있는 신뢰할 수 있는 추가 개발자가 필요할까요?

@cloudhead 저는 WinLess를 사용하여 LESS 코드를 컴파일합니다... WinLess는 less.js의 최신 배포판과 함께 제공됩니다(https://github.com/marklagendijk/WinLess/issues/14 참조). ) 최신 릴리스에 추가됩니까?

감사합니다(훌륭한 제품).

그래서, 어... 우리는 어떻게 하고 있나요?

@jreading 커밋 cb7893 으로 git에서 수정되었다고 생각합니다.

수정된 것으로 보이며(또는 최소한 원래 문제는 있음) 그렇지 않은 경우 이 문제를 해결하는 또 다른 버그가 있을 것입니다.