Less.js: data-uri 함수는 파일 경로가있는 문자열이 아닌 data-uri 호출 경로를 사용합니다.

이 변경 사항이 주요 변경 사항인지 버그 수정인지에 대한 피드백을 환영합니다.

참고 : 아주 간단한 방법으로 이전 버전과의 호환성을 깨지 않고 우아하게 구현할 수 있습니다.

현재 data-uri() 함수는 문자열을 파일 경로로 포함하는 Quoted 트리 노드를 허용하고 함수 호출을 포함하는 파일 위치에 대한 URL로 내부적으로 해석합니다. data-uri 함수를 오버로드하여 실제 URL을 보유한 Url 트리 노드도 허용 할 수 있습니다. 이렇게하면 URL이 url() CSS 함수가 호출 된 위치에 대해 정규화되어야하며 더 이상 data-uri() Less 함수에서 내부적으로 정규화되지 않아야합니다.

예

// app/content/button.less
button {
  .background(url("images/btn.jpg"));
}

뿡뿡

나에게는 수정이 아닌 해결 방법처럼 보입니다. 추가 반복에서 그들은 url 를 믹스 인으로 이동하여 자세한 내용을 피하려고 _ 할 것이며 _ 문제가 다시 발생합니다. 또 다른 문제는이 문제가 발생한 원래 사용 사례 (# ​​2541)를 취하면 다음과 같이 자주 사용된다는 것입니다.

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

(예를 들어 글꼴-페이스 믹스 인의 경우 일반적으로 여러 woff , ttf , eot , eot?#iefix 등이 같은 파일 이름에 추가됩니다. ). 이렇게하면 이전 url 도 불가능합니다.

@ seven-phases-max

그렇다면 적절한 해결 기간이 있다고 생각하지 않습니다. 상대 URL이 해석되어야하는 컨텍스트를 판별하는 방법이 필요합니다. data-uri() 함수에 들어가는 문자열 값을 정의한 파일의 파일 정보에서 해당 컨텍스트를 가져 오거나 url() 함수와 Url 트리 노드.

경로 변수 대체를 지원하려면 경로의 다양한 부분을 정규화해야하는 방법을 파악해야하기 때문에 상황이 빠르게 까다로워집니다.

예를 들어, 다음과 같이 어떻게 정규화합니까?

// mixins.less
.background(@image) {
    background-image: data-uri("../../@{image}.jpg");
}
// app/content/button.less
button {
  .background("../images/btn");
}

상대 URL 확인과이 두 경로의 토큰 대체 기반 조합을 어떻게 결합 하시겠습니까?

한 가지 옵션은 대체자 토큰이 url() 또는 data-uri() 로 들어가는 최종 URL 값의 머리에있을 때 대체자 토큰으로 대체되는 문자열을 정의하는 파일에 대해서만 해결하는 것이라고 생각합니다.

또 다른 해결책은 경로를 결합하거나 파일 확장자를 추가 / 제거 / 편집하는 일부 경로 처리 기능을 도입하고 ( unit() 함수가 차원에 대해 작동하는 방식과 유사합니까?) 상황을 더 명확하게 만드는 것입니다.

예

// mixins.less
.background(@image) {
    background-image: data-uri(extension(<strong i="21">@image</strong>, "jpg"));
}
// app/content/button.less
button {
  .background(url("./images/btn"));
}

첫 번째 예에서는 특별한 정규화가 필요하지 않습니다. "../../@{image}.jpg" 는 작성된대로 "../../../images/btn.jpg" 확장됩니다 (그런 다음 경로를 처리하는 데 최대 data-uri 됩니다).
그리고 두 번째 예는 단지 ... 함수를 쌓아서 이전 버전과의 호환성을 해결하기 위해 함수를 쌓는 것입니다 ... 정확히 무엇입니까? 다른 파일에 정의 된 믹스 인을 호출 할 때 _ 잘못된 _ 파일 경로?

어쨌든 .background(url("images/btn.jpg")); 와 함께 "예상대로"_only_ 작동해야한다면, 변경없이 직접 .background(data-uri("images/btn.jpg")); 를 작성하는 것과 어떻게 다른가요? :)

즉, 이것이 고쳐진다면 그것이 아무리 깨져도 data-uri 로 고정 된 해협이되어야한다는 것입니다. (솔직히 더 나은 전략이 무엇인지 모르겠습니다 : a. 이에 대한 더 많은 보고서 / 요청을 기다린 다음 (충분한 경우) 변경하거나 b. 가능한 중단 영향을 최소화하기 위해 더 일찍 수정하십시오).

_{즉, url 및 data-uri 가 처음에 상호 교환 가능하도록 설계되었다고 가정합니다 (즉, data-uri 는 url 의 특수 버전 일 뿐이며 CSS url 컴파일됩니다 ulr "이렇게"(같은 옵션 포함) 동작하는 반면 data-uri 가 "그렇게"( 이와 같은 옵션), 특정 동작을 얻으려면 data-uri(url()) 콤보가 필요합니다. 믹스 인 내에서 " data-uri 제한되고 url _out_로 제한됩니다 --relative-urls: on "<-Bhrrrr ... :)}

나에게는 수정이 아닌 해결 방법처럼 보입니다. 추가 반복에서 그들은 url을 mixin으로 이동하여 자세한 정보를 피하려고 시도 할 것이며 문제가 다시 발생합니다.

네 동의합니다.

나는 v3 릴리스를 위해 더 적은 노력을 기울이고 이것을 고치기 위해 천천히 노력하고 있습니다.

가능한 모든 파일 경로를 찾아서 하나씩 시도 할 생각이었습니다. 다른 위치에 여러 파일이있는 경우 약간 지루하지만 ...이 문제를 완전히 고칠 수는 없다는 데 동의하지만 적어도 정상적인 경우를 고칠 수 있습니다.

아마도 resolve() 함수는 해결 된 URL을 함수에 전달하는 데 도움이 될 수 있습니다 (하지만 작동하지 않는 완전한 경로가 아니고 이것이 수정되었을 때 완전한 경로가 작동하는 경우 ...)

빨리 생각을 적어서 죄송합니다.

이것은 간단한 메모 일 뿐이지 만 변수 보간을 사용하여 가져 오기와 동일한 문제가 발생합니다.

변수 보간을 사용하여 가져 오기.

그것은 흥미롭고 불안합니다.
실제로 지원되는 사용 사례입니까 아니면 우연의 일치입니까?

@rjgotten 지원되지만 지원이 다소 제한됩니다. # 410에서 추적되었습니다.

이것은 작동합니다 :

<strong i="8">@variable</strong>: "path.less";
<strong i="9">@import</strong> "@{variable}";

이것은하지 않습니다 :

.mixin(@variable) {
  <strong i="13">@import</strong> "@{variable}";
}

편집 : 링크가 작동하도록 수정되었습니다.

믹스 인에서 @import 변수를 지원하고 싶은지 잘 모르겠습니다.
전체 변수 가져 오기는 약간의 마술이고 반 직관적 인 코드를 만들 수 있습니다. 그래서 저는 그것을 권장하지 않습니다.

해결 방법에 대한 많은 논의가 있습니다. 실제 문제를 해결할 수 있습니까? data-uri가 처리중인 파일에 상대적이어야한다는 것이 분명하지 않습니까?

지금은 다른 경로에서 _a reference_를 가져 오는 파일이 있으며 여전히 data-uri에 대해 불평합니다. 적어도 그것은 버그 일 것입니까? 참조로 가져 오면 현재 파일과 관련된 경로를 다시 쓰지 않아야 함을 의미합니다.

@Ciantic

참조로 가져 오면 현재 파일과 관련된 경로를 다시 쓰지 않아야 함을 의미합니다.

정확히 무엇을 바탕으로? reference 와 무슨 관련이 있습니까?

지금은 다른 경로에서 참조를 가져 오는 파일이 있으며 여전히 data-uri에 대해 불평합니다.

위의 문제와 반대되는 것 같습니다. 더 자세한 정보를 제공해 주시겠습니까? (예 : 가져 오기, 가져 오기 및 데이터 파일의 경로 등).

styles.less

.something {
    background: data-uri("some.svg");
}

sub / test.less

<strong i="11">@import</strong> (reference) "../style.less";
.test {
    color: green;
}

style.less를 컴파일하지만 test.less에 상대적인 data-uri를 사용하려고하기 때문에 test.less가 아닙니다.

참조 가져 오기가 경로를 다시 작성하려고 시도하는 이유는 내 의견으로는 참조를 사용할 때 필요하지 않습니다.

data-uri가 옵션의 URL 재 작성 규칙을 따르기를 기대합니다. 물론 .... 그것이 data-uri에서 실제로 의미하는 바를 말하기는 어렵습니다.

일반적으로 data-uri는 ".less 파일 호출"을 기준으로 확인되어야합니다. 따라서 믹스 인의 경우 믹스 인 위치가 아니라 믹스 인이 호출 된 위치를 기준으로 확인되어야합니다. 믹스 인은 이러한 진술을 "혼합"한 다음 해결합니다. 그래서 @lukeapage 귀하의 해석이 정확하다고 생각합니다.

// app/content/button.less
button {
  .background("images/btn.jpg");
}

app/content/images/ 에서 btn.jpg를 찾아야합니다. 그렇지 않은 경우 믹스 인이 작동하는 방식이 아니기 때문에 버그입니다. 나는 그것이 "브레이킹 체인지"가 아니라 버그 수정이라고 생각합니다.

즉 ... 다음과 같이 해결하는 데 문제가 없다고 생각합니다.

1. 발신자와 관련하여 해결을 시도합니다.
2. 믹스 인과 관련하여 해결하려고합니다.

Node.js는 해결을 위해 여러 경로를 시도합니다. 해결 순서가 명확하게 문서화되어 있으면 기대치를 관리 할 수 ​​있습니다. 그리고 그렇게하는 것은 누군가가 행동 # 2를하지 않았다면, 모든 경우는 아니더라도 거의 모든 상황에서 여전히 작동 할 것임을 의미합니다.

@ 매튜 딘
일반적으로 data-uri는 ".less 파일 호출"을 기준으로 확인되어야합니다. 따라서 믹스 인의 경우 믹스 인 위치가 아니라 믹스 인이 호출 된 위치를 기준으로 확인되어야합니다. 믹스 인은 이러한 진술을 "혼합"한 다음 해결합니다.

일반적으로 모든 사용 사례에 대해 올바른 방식으로 작동하도록 만들 수는 없습니다.

예를 들어, 대체 토큰이 채워진 일부 알려진 기본 폴더에 대해 해결되어야하는 매개 변수화 된 URL, 즉 대체 토큰이있는 URL을 어떻게 지원합니까? 이 경우에는 호출자의 파일이 아닌 수신자의 파일에 대한 재 등록이 필요합니다.

나는 콜 사이트에서 url() 를 명시 적으로 사용하지 않고 이것을 투명하게 수정하는 방법에 대해 약간의 깨달음을 얻었습니다. @ seven-phases-max는 당연히 나쁜 생각이라고 부릅니다 (누군가가 결국 _will_ 시도하기 때문입니다. mixin 호출로 리팩터링하고 작업을 중단하십시오) :

Quoted 리터럴 노드가 생성되면 해당 파일 정보를 유지합니다. 변수 할당, 믹스 인 호출 등을 통해 해당 정보를 전파합니다. 호출자 파일에서 생성 된 모든 Quoted 값은 url() 또는 data-uri() 로 처리 될 때 해당 호출자 파일에 대해 확인됩니다. . 그러나 믹스 인의 내부 로직의 일부인 Quoted 값은 여전히 ​​믹스 인의 로컬 파일에 대해 해결됩니다.

모든 것이 예상대로 작동하도록 유지하고 다음과 같은 대체 문자열을 사용하여 시나리오를 저장합니다.

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

이를 고칠 수있는 트릭도 있습니다. 대체 토큰을 채울 때 토큰이 대체 문자열의 맨 처음에 있으면 결과 문자열은 채워진 토큰에서 파일 정보를 상속해야합니다. 대체 문자열의.

mixin 자체 작성자의 의도가 mixin 파일에 대해 이러한 경로를 확인하는 것이라면 "./@{image}.jpg" 를 패턴으로 사용하여 해당 작업을 수행 할 수 있습니다. 이를 통해 전화를 건 사람의 책임 부담을 효과적으로 이동시킬 수 있습니다.

// _mixins.less
.sprite(@image) {
    background: data-uri("../images/sprites/@{image}.png") no-repeat;
}

// main.less
div {
   .sprite('logo');
}

산출:

div {
   background: url(data:image/png;base64,...) no-repeat;
}

와우, 이것은 아주 오래된 것입니다 ....이 문제는 저에게도 영향을 미칩니다.

url 함수에 옵션을 추가하거나 URL을 절대적으로 해결할 새 함수를 만드는 것은 어떻습니까? 이렇게하면 mixin이 설정된 위치에 관계없이 절대 경로로 작동하고 실수의 여지가 없습니다.

url 함수에 옵션을 추가하거나 URL을 절대적으로 해결할 새 함수를 만드는 것은 어떻습니까? 이렇게하면 mixin이 설정된 위치에 관계없이 절대 경로로 작동하고 실수의 여지가 없습니다.

여기서 문제는 절대 경로와 상대 경로에 관한 것이 아닙니다. 호출 사이트에 대한 상대 대 선언 사이트에 대한 상대였습니다. 완전히 다른 문제입니다.

문제가 발전했을 수도 있지만, 초기 주석과 제목은 데이터 -uri가 호출 된 파일과 관련된 경로를 해결하는 것에 관한 것이며, 다른 곳에 배치 된 믹스 인과 결합하면 경로가 잘못 해결 될 수 있습니다. 그게 제가 겪고있는 문제입니다.

그렇다면 솔루션으로서 절대 경로는 어디에 영향을 미칠까요?

data-uri가 절대 경로를 받아들이고 신관적인 absolute-url 함수가 있다고 가정하면 다음 코드는 믹스 인 위치에 관계없이 작동합니다.

// mixins.less
.background(@image) {
    background-image: data-uri(@image);
}

// app/content/button.less
button {
  .background(absolute-url("images/btn.jpg"));
}

@ miljan-aleksic "절대"란 data-uri 위치에있는 파일과 관련이 있다는 뜻입니까? 그렇다면 "절대적"은 아마도 잘못된 용어 일 것입니다.

URL에 대한 기능적 래퍼처럼 모든 URL을 파일 상대로 만드는 것이 좋은 접근 방식입니다. 또는 url ()에 대한 추가 인수입니다.

@ matthew-dean, 절대적으로 파일의 전체 경로를 의미합니다. 예 : /users/myuser/projects/lessproject/icon.svg .

url ()이 ubication을 알지 못하고 data-uri 위치 파일에 대한 상대 경로를 만드는 방법을 알지 못하기 때문에 접근 방식을 얻지 못합니다.

URL에 대한 기능적 래퍼처럼 모든 URL을 파일 상대로 만드는 것이 좋은 접근 방식입니다. 또는 url ()에 대한 추가 인수입니다.

충분히 재미있게; 이것이 제가 몇 년 전에 제안한 것입니다. ;-)

절대적으로 파일의 전체 경로를 의미합니다. 예 : /users/myuser/projects/lessproject/icon.svg.

이 absolute-url 함수는 absolute-url 함수가 호출 된 파일의 위치를 ​​기반으로 전체 출력 경로에 전달 된 상대 경로를 _pre-resolves_합니다. 컴파일 된 출력 CSS 파일이 이동할 위치를 기준으로합니다.

즉, 둘 다 같은 뜻입니다. 그 당시 나처럼.

컴파일 된 출력 CSS 파일이 이동할 위치를 기준으로 absolute-url 함수가 호출되는 파일의 위치를 ​​기준으로 전체 출력 경로로 지정됩니다.

에서와 같이 재 작성 URL 또는 루트 경로는 여전히 적용되지만 정의 위치를 ​​기반으로합니까? 이는 출력과 관련된 URL이 아니라 _ ​​컴파일 중 _ URL에 대해 이야기하는 @lukeapage 의 원래 예제와는 약간 다른 것 같습니다. 예 : data-uri() 위치.

따라서이 문제는 사람들이 유사하지만 정확히 동일한 문제에 대해 게시했기 때문에 추적하기가 약간 어렵습니다. 즉, 상대 _source_를 변경하려면 상대 _output_을 변경하는 것과는 훨씬 다른 솔루션이 필요할 수 있습니다. 아니면 아닐 수도 있습니다. 경로 지정 논리에 따라 다릅니다. 그러나 data-uri가 출력으로 어떤 경로도 생성하지 않는다는 점을 분명히해야합니다.

resolve() 같은 것이 필요할까요? 몰라요, 그냥 뱉어 내지 만 url(resolve(file(), "my/path")) ? @ miljan-aleksic이 absolute() 에서 의미하는 바는 절대 URL로 해석된다는 점에서 그렇습니다. 그러나 여전히 입력을 받아야합니다 (예 file() , 해결하려면). 그렇지 않으면 file-resolve() 와 같은 작업을 수행하여 해당 논리를 하나의 함수에 지정할 수 있지만 resolve() 및 file() 를 두 개의 함수로 사용하는 것이 개별적으로 유용 할 수 있습니다.

이 모든 것에 대한 까다로운 부분은 모든 재 작성 URL 옵션이며, 그 중 이제 모듈 지원을 추가 한 PR 병합에 대해 더 많은 옵션이 있습니다. (https://github.com/less/less.js/pull/3248). 그렇다면 파일 상대 URL을 반환해도 다시 작성할 수 있습니까? 그렇다고 생각하지만 명확해야합니다.

예, resolve () 및 file ()은 내가 설명하려는 내용을 정확히 정의합니다. 가까운 장래에 이것이 구현 될 수 있기를 바랍니다.

@ miljan-aleksic 좋아요, 그럼 말이 되네요.

사실, file() 는 옳지 않습니다. 내가 생각하는 파일 이름을 반환하므로 dir() 와 비슷합니다. 그리고 아마도 파일 당 변수 상수 여야합니다.

는 어때:

data-uri(resolve(<strong i="10">@DIR</strong>, "my/path"))

따라서 두 가지가 추가되었습니다. 1) 경로를 결합하는 resolve () 함수, 2) 평가하는 동안 각 파일에 삽입 된 @DIR (및 @FILE ?) 상수. 그것에 대한 유일한 까다로운 점은 주입 된 변수가 루트의 다른 변수를 재정의하거나 병합하지 않는지 테스트하는 것입니다.하지만 테스트하기는 매우 간단해야합니다. 아니면 @arguments 처럼 소문자 여야합니까? 이 경우 충돌을 피하기 위해 @directory 및 @filename 를 제안합니다. 가장 적은 옵션은 무엇입니까?

resolve() 같은 것이 필요할까요?

^ 빙고. 정확합니다.

가장 적은 옵션은 무엇입니까?

Node.js-y 옵션을 선택하겠습니다 : __dirname
그것은 오랫동안 주변에 있었고 잘 알려져 있습니다. Less에서 동일한 개념에 동일한 이름을 사용하는 것이 좋습니다.

Node.js-y 옵션을 선택하겠습니다 : __dirname

Err ... Less / CSS 키워드 나 Less 변수 또는 함수 의미와 일치하지 않습니다. 우리는 그것보다 더 잘해야합니다. @__dirname 아마도 언어에 대해서는 밑줄이 약간 이상합니다. 전혀 맞지 않습니다.

밑줄은 언어에 대해 여전히 약간 이상합니다. 전혀 맞지 않습니다.

이중 밑줄은 많은 언어에서 '시스템이 제공하는 것'을 나타내는 데 사용되며, 특히 내재 변수와 같은 경우에 특히 그렇습니다. 따라서 위치를 벗어난 것이 일종의 요점입니다.

물론이야; 마음에 들지 않으면 @dirname 또는 @dir-name 와 같은 파생 상품을 사용할 수 있습니다.

그러나 이것에 대해 좀 더 생각해 보면 왜 우리는 변수로 노출 된 현재 파일 경로를 _ 필요로 하는가? 개념적인 resolve() 함수 자체에 통합 할 수 없습니까?

개념적 resolve () 함수 자체에 통합 될 수 없습니까?

그리고 우리는 다른 함수 이름으로 제 제안으로 돌아 왔습니다. 나는 여전히 그것을 가장 좋아하고 resolve ()만큼 더 좋습니다.

그리고 우리는 다른 함수 이름으로 제 제안으로 돌아 왔습니다.

일종의.

내가 얻는 것은 resolve() 함수에 대한 호출을 보유하는 파일의 URL / 경로를 전달할 필요가 없다는 것입니다. 해당 위치는 함수에 대해 _known_이어야하기 때문입니다.

함수 내 this 는 currentFileInfo 속성이있는 FunctionCaller 인스턴스를 참조합니다.
해당 속성은 함수 호출에 해당하는 Call AST 노드의 파일 정보로 초기화됩니다.
즉

https://github.com/less/less.js/blob/4e903e8254cc20fec80fccd35794fb797949e653/lib/less/tree/call.js#L47

코드를 올바르게 읽고있는 경우 파일 정보는 함수 호출이 평가되는 파일이 아니라 함수 호출이 _declared_ 인 위치의 파일 정보에 해당합니다.

즉, 'eager'URL 리졸버를 위해이 파일 정보를 사용해도 괜찮습니다. 함수 호출이 다른 파일의 컨텍스트 내에서 가져 와서 평가되는 믹스 인 내부에 배치 되더라도 예상대로 작동합니다. 즉 : 믹스 인이 정의 된 파일에 고정 된 해상도로.

그러나 이에 대해 좀 더 생각해 보면 왜 현재 파일 경로가 변수로 노출되어야합니까? 개념적 resolve () 함수 자체에 통합 될 수 없습니까?

아무도 현재 파일이나 일반 리졸버 함수가 필요하지 않다고 확신하는 경우 ... 아마도 ... 명시 적 로컬 var가 일반 함수가 아니며 함수가 다음과 같이 평가되지 않음을 분명히합니다. 다른 기능. 그것이 나의 진정한 관심사이며 의미론입니다. 이름에 상관없이 "현재 파일"에 대한 특별한 "마커"가 없다면 입력에 따라 동일하게 해결되는 다른 함수와는 다릅니다. 즉, 보이지 않는 입력에 따라 해결되는 기능이며 저와 관련이 있습니다. 그러나 함수가 current-file-resolve() 과 같이 매우 명시 적이라면 충분히 명확 할 수 있습니다. 그렇지 않으면 mixin이 정의 된 파일 대신 mixin 호출이 호출 된 파일에 따라 specialfunction() 해결하지 못한 이유를 사람들에게 혼동하게됩니다.

따라서 아니요, 로컬 변수는 기술적으로 _needed_가 아니지만 의미 / 출력 / 동작은 의미에서 명확해야합니다.

흠 ...

확인. 그런 다음 resolve-url(url, [base]) 함수-옵션 인 base 가있는 것은 어떻 this.fileInfo 만 가져 와서 경로를 가져 오는 declared-dir() 함수를 사용합니다. 다른 파일에서 경로를 가져오고 싶습니다. 또는 URL 확인과 관련이없는 다른 기능의 일부로 사용해야합니다.

즉, 전체 양식 호출 (암시 적 기반 없음)은 다음과 같습니다.

resolve-url("../foo", declared-dir())

... 그리고 그냥하는 것과 같습니다

resolve-url("../foo")

... 이는 게으른 사람에 해당하는 열망입니다.

url("../foo")

그런 식으로 '자동'주입 된 변수는 필요하지 않습니다. 이것은 순전히 일련의 플러그인 기능으로 구현 될 수 있다고 생각합니다. 그리고 우리가 필요로하는 유일한 핵심 메커니즘은 URL을 '이미 해결됨'으로 표시하여 resolve-url 함수에서 나오는 URL에서 기본 확인자 논리가 실행되지 않도록 차단할 수있는 방법입니다.

의미론은 과정 문서에서 명확해야합니다. 그리고 그 문서는 url 와 resolve-url 를 명시 적으로 비교하여 열망하고 게으른 평가 / 해결 방법을 설명 할 수 있습니다.

_{가져온 파일의 범위가 동일하기 때문에 "주입 된 변수"아이디어가 어쨌든 작동하지 않는 경우 (추가 해킹없이).}

<strong i="7">@__dir</strong>: "whatever";
// *everywhere* it's the only <strong i="8">@__dir</strong> value = the path of "c"
<strong i="9">@import</strong> "a";
<strong i="10">@import</strong> "b";
<strong i="11">@import</strong> "c";

함수 기반 구현에 대해 말하자면, this.context.? 또는 this.context.frames[?] 어딘가에서 함수가 호출되는 파일의 경로를 여전히 얻을 수 있다고 생각합니다 (확신 할 수는 없습니다). 정도.

음, 문제를 해결할 더 좋은 방법이 없나요?

안녕하세요.
음, 문제를 해결할 더 좋은 방법이 없나요?

게으른 평가로 인해 제대로 해결하기가 매우 어렵습니다.

@ seven-phases-max
함수 기반 구현에 대해 말하자면, this.context.? 또는 this.context.frames[?] 어딘가에서 함수가 호출되는 파일의 경로를 여전히 얻을 수 있다고 생각합니다 (확신 할 수는 없습니다). 정도.

계층 구조에서 Call 노드를 찾을 수 있어야합니다.