Less.js: fungsi data-uri menggunakan jalur panggilan data-uri, bukan string dengan jalur ke file masuk.

Saya menyambut umpan balik tentang apakah ini adalah perubahan yang melanggar (menjamin peningkatan besar) atau perbaikan bug.

FYI: Anda dapat menerapkan ini dengan elegan tanpa merusak kompatibilitas mundur dengan cara yang sangat sederhana.

Saat ini fungsi data-uri() menerima simpul pohon Quoted memegang string sebagai jalur file dan menyelesaikannya secara internal sebagai URL terhadap lokasi file yang menahan pemanggilan fungsi. Anda dapat membebani fungsi data-uri untuk juga menerima simpul pohon Url memegang URL sebenarnya. Dengan cara ini URL harus dinormalisasi terhadap lokasi di mana fungsi url() CSS dipanggil dan seharusnya tidak lagi dinormalisasi secara internal dalam fungsi data-uri() Less.

Misalnya

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

@bayu_joo

Bagi saya ini lebih terlihat seperti solusi daripada perbaikan. Pada iterasi lebih lanjut, mereka _will_ mencoba menghindari verbositas dengan memindahkan url ke mixin dan masalah muncul lagi. Masalah lainnya adalah mengambil kasus penggunaan asli dari mana masalah ini berasal (# 2541), sering kali digunakan seperti ini:

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

(Misalnya untuk mixin font-face sebagai contoh biasanya beberapa woff , ttf , eot , eot?#iefix dll. Ekstensi ditambahkan ke nama file yang sama ). Dan cara ini sebelumnya url juga tidak mungkin.

@ tujuh-fase-maks

Maka saya tidak benar-benar berpikir ada periode solusi yang cocok. Anda memerlukan beberapa cara untuk menentukan konteks yang harus diselesaikan oleh URL relatif. Entah Anda mengambil konteks itu dari info file dari file yang menentukan nilai string yang masuk ke fungsi data-uri() , atau Anda membuat titik potong lebih eksplisit melalui fungsi url() dan Url simpul pohon.

Jika Anda ingin mendukung substitusi variabel jalur, maka segala sesuatunya menjadi rumit dengan cepat karena Anda perlu mencari tahu bagaimana berbagai bagian jalur perlu dinormalisasi.

Misalnya, bagaimana Anda menormalkan sesuatu seperti:

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

Bagaimana Anda akan menggabungkan resolusi url relatif dan kombinasi yang didorong substitusi token dari dua jalur tersebut?

Saya kira satu opsi adalah hanya menyelesaikan file yang menentukan string yang diganti dengan token pengganti, ketika token pengganti berada di bagian atas nilai URL final menjadi url() atau data-uri() function dan abaikan kasus seperti di atas. Sepertinya itu paling logis.

Solusi lain bisa jadi dengan memperkenalkan beberapa fungsi penanganan jalur untuk menggabungkan jalur atau menambah / menghapus / mengedit ekstensi file (mirip dengan cara kerja fungsi unit() untuk dimensi, mungkin?) Dan membuatnya lebih eksplisit.

Misalnya

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

Untuk contoh pertama Anda, ini tidak memerlukan normalisasi khusus, "../../@{image}.jpg" diperluas menjadi "../../../images/btn.jpg" seperti yang tertulis (dan kemudian hingga data-uri untuk menangani jalur).
Dan contoh kedua hanyalah ... menumpuk fungsi untuk mengatasi fungsi untuk mengatasi kompatibilitas mundur dengan ... apa sebenarnya? Jalur file _Wrong_ saat memanggil mixin yang ditentukan di file lain?

Lagi pula, apakah itu akan bekerja "seperti yang diharapkan" _only_ dengan .background(url("images/btn.jpg")); , apa bedanya dengan hanya menulis .background(data-uri("images/btn.jpg")); secara langsung tanpa perubahan sama sekali? :)

Dengan kata lain yang saya maksud adalah bahwa jika ini akan diperbaiki maka itu harus diperbaiki dengan data-uri tidak peduli seberapa besar kerusakannya. (Sejujurnya saya tidak tahu strategi apa yang lebih baik: a. Menunggu lebih banyak laporan / permintaan untuk ini dan kemudian (jika jumlahnya cukup) ubah atau b. Modifikasi lebih awal untuk meminimalkan kemungkinan dampak kerusakan).

_{Dengan kata lain, dengan asumsi url dan data-uri pada awalnya dirancang sebagai dapat dipertukarkan (yaitu data-uri hanyalah versi khusus dari url (dan dikompilasi ke CSS url pada akhirnya)), akan sangat menyakitkan untuk menjelaskan mengapa tepatnya ulr berperilaku "seperti ini" (dengan opsi seperti itu) sementara data-uri berperilaku "seperti itu" (dengan opsi seperti ini), dan untuk mendapatkan perilaku tertentu Anda memerlukan data-uri(url()) combo, terbatas pada " data-uri di dalam campuran dan url _out_ dengan --relative-urls: on "<- Bhrrrr ... :)}

Bagi saya ini lebih terlihat seperti solusi daripada perbaikan. Pada iterasi lebih lanjut, mereka akan mencoba menghindari verbositas dengan memindahkan url ke mixin dan masalah muncul lagi.

Ya saya setuju.

Saya perlahan mencoba membangun untuk menempatkan lebih banyak upaya menjadi lebih sedikit untuk rilis v3 dan hanya memperbaikinya.

Saya berpikir untuk mengerjakan semua jalur file yang mungkin dan mencobanya satu per satu - meskipun itu agak buruk jika ada banyak file di lokasi yang berbeda ... Saya pikir saya setuju tidak mungkin untuk sepenuhnya memperbaiki ini selamanya, tetapi setidaknya kami dapat memperbaiki kasus normal.

Mungkin fungsi resolve() dapat membantu meneruskan url yang telah diselesaikan ke fungsi (tetapi jika itu bukan jalur lengkap yang tidak akan berfungsi dan jalur lengkap akan berfungsi saat ini diperbaiki ...)

Maaf, baru saja mencatat pikiran dengan cepat.

Ini hanya sebuah catatan singkat, tapi kita akan memiliki masalah yang sama dengan import menggunakan interpolasi variabel.

impor menggunakan interpolasi variabel.

Itu menarik dan meresahkan.
Apakah ini benar-benar kasus penggunaan yang didukung atau kebetulan yang menyenangkan?

@rjgotten Itu didukung, namun dukungan agak terbatas. Itu dilacak di # 410

Ini bekerja:

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

Ini tidak:

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

Edit: dimodifikasi agar tautan berfungsi.

Saya tidak yakin saya ingin mendukung variabel @import di mixin.
Seluruh variabel impor agak ajaib dan dapat membuat beberapa kode kontra-intuitif .. jadi saya lebih suka mencegah itu.

Banyak diskusi tentang solusi, mungkin hanya memperbaiki masalah yang sebenarnya? Bukankah sudah jelas bahwa data-uri harus relatif terhadap file yang sedang diproses.

Saat ini saya memiliki file yang mengimpor _a referensi_ dari jalur lain, dan masih mengeluh tentang data-uri. Setidaknya itu pasti bug? Maksud saya, jika saya mengimpor dengan referensi, seharusnya tidak mencoba menulis ulang jalur ke relatif terhadap file saat ini.

@Santrikece

Maksud saya, jika saya mengimpor dengan referensi, seharusnya tidak mencoba menulis ulang jalur ke relatif terhadap file saat ini.

Berdasarkan apa sebenarnya? Apa hubungannya dengan reference ?

Saat ini saya memiliki file yang mengimpor referensi dari jalur lain, dan masih mengeluh tentang data-uri.

Kedengarannya berlawanan dengan masalah di atas. Bisakah Anda memberikan detail lebih lanjut? (misalnya, jalur pengimporan, impor, dan file data, dll.).

styles.less

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

sub / test.less

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

Ini mengkompilasi style.less, tetapi bukan test.less karena mencoba menggunakan data-uri relatif terhadap test.less.

Mengapa referensi impor mencoba melakukan penulisan ulang jalur, itu tidak perlu saat menggunakan referensi menurut saya.

Saya berharap data-uri mengikuti aturan penulisan ulang url dalam opsi. Tentu saja .... sulit untuk mengatakan apa artinya sebenarnya dengan data-uri.

Secara umum, data-uri harus menyelesaikan relatif terhadap "file panggilan .less". Jadi dalam kasus mixin, ia harus menyelesaikan relatif ke tempat mixin disebut, bukan relatif ke lokasi mixin. Mixin "mencampurkan" pernyataan-pernyataan itu dan kemudian menyelesaikannya. Jadi @lukeapage saya pikir interpretasi Anda benar:

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

Ini harus mencari btn.jpg di app/content/images/ . Jika tidak, itu bug karena ini bukan cara kerja mixin. Saya tidak berpikir ini adalah "perubahan yang merusak" tetapi perbaikan bug.

Yang mengatakan ... Saya tidak berpikir akan ada masalah dengan penyelesaian seperti:

1. Mencoba menyelesaikan secara relatif terhadap penelepon.
2. Mencoba menyelesaikan relatif terhadap mixin.

Node.js mencoba beberapa jalur untuk resolusi. Selama urutan penyelesaian didokumentasikan dengan jelas, Anda dapat mengelola ekspektasi. Dan melakukannya seperti itu berarti bahwa jika seseorang mendasarkan perilaku .less to do mereka # 2, itu masih akan berhasil di hampir semua, jika tidak semua kasus.

@ dekan
Secara umum, data-uri harus menyelesaikan relatif terhadap "file panggilan .less". Jadi dalam kasus mixin, ia harus menyelesaikan relatif ke tempat mixin disebut, bukan relatif ke lokasi mixin. Mixin "mencampurkan" pernyataan-pernyataan itu dan kemudian menyelesaikannya.

Anda tidak akan pernah bisa membuatnya bekerja dengan cara yang umumnya benar untuk semua kasus penggunaan.

Misalnya, bagaimana Anda mendukung url parametrized, yaitu url dengan token pengganti, yang harus diselesaikan terhadap beberapa folder dasar yang diketahui dengan hanya mengisi token pengganti? Kasus itu membutuhkan pemulihan terhadap file callee, bukan file pemanggil.

Saya mendapat sedikit pencerahan tentang cara memperbaikinya secara transparan tanpa penggunaan eksplisit url() di situs panggilan, yang oleh @ seven-phases-max berhak disebut sebagai ide yang buruk (karena seseorang akhirnya _will_ mencoba untuk refactor ke dalam panggilan mixin dan hancurkan hal-hal):

Ketika literal Quoted node dibuat, simpan info filenya. Sebarkan info itu melalui tugas variabel, panggilan mixin, dll. Setiap nilai Quoted berasal dari file pemanggil akan, ketika diperlakukan oleh url() atau data-uri() , diselesaikan terhadap file pemanggil itu . Tetapi nilai Quoted yang merupakan bagian dari beberapa logika internal mixin masih diselesaikan terhadap file lokal mixin.

Itu membuat semuanya berfungsi seperti yang diharapkan, kecuali untuk skenario dengan string substitusi seperti di:

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

Ada trik yang dapat Anda lakukan untuk memperbaikinya juga: saat mengisi token subsitusi, jika token berada di awal string substitusi, string yang dihasilkan harus mewarisi info file dari token yang telah diisi, bukan dari itu dari string subsitusi.

Jika maksud dari pembuat mixin sendiri adalah memiliki jalur yang diselesaikan terhadap file mixin, mereka masih dapat membuatnya berfungsi dengan menggunakan, misalnya, "./@{image}.jpg" sebagai pola. Itu secara efektif mengalihkan beban tanggung jawab dari penelepon, yang Anda inginkan.

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

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

keluaran:

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

Wow, ini sangat lama .... dua sen saya karena masalah ini mempengaruhi saya juga.

Bagaimana dengan menambahkan opsi ke fungsi url, atau membuat fungsi baru, yang akan menyelesaikan url sebagai absolut. Dengan begitu, di mana pun mixin diatur, ini akan berfungsi dengan jalur absolut dan tidak ada ruang untuk kesalahan.

Bagaimana dengan menambahkan opsi ke fungsi url, atau membuat fungsi baru, yang akan menyelesaikan url sebagai absolut. Dengan begitu, di mana pun mixin diatur, ini akan berfungsi dengan jalur absolut dan tidak ada ruang untuk kesalahan.

Masalahnya di sini bukanlah tentang jalur absolut vs relatif. Itu tentang relatif terhadap situs panggilan vs relatif terhadap situs deklarasi. Masalah yang sama sekali berbeda.

Mungkin masalah telah berkembang, tetapi komentar dan judul awal adalah tentang data-uri yang menyelesaikan jalur sehubungan dengan file tempat ia dipanggil, yang bila digabungkan dengan mixin yang ditempatkan di tempat lain dapat menyelesaikan jalur secara tidak benar. Nah, itulah masalah yang saya alami.

Jadi, di mana faktor jalur absolut itu sebagai solusi?

Dengan asumsi data-uri menerima jalur absolut dan ada fungsi hipotetik absolute-url , kode berikut akan berfungsi di mana pun mixin ditempatkan.

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

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

@ miljan-aleksic Yang Anda maksud dengan "absolut" terkait file di lokasi data-uri ? Jika demikian "absolut" mungkin istilah yang salah.

Sepertinya pembungkus fungsional untuk url untuk membuat file-relatif url adalah pendekatan yang baik. Atau argumen tambahan ke url ().

@ matthew-dean, yang saya maksud adalah path lengkap ke file tersebut, misalnya: /users/myuser/projects/lessproject/icon.svg .

Saya tidak mendapatkan pendekatan Anda karena saya tidak melihat bagaimana url () dapat membuat jalur relatif ke file lokasi data-uri tanpa mengetahuinya.

Sepertinya pembungkus fungsional untuk url untuk membuat file-relatif url adalah pendekatan yang baik. Atau argumen tambahan ke url ().

Cukup lucu; itu hampir seperti yang saya sarankan beberapa tahun yang lalu. ;-)

yang saya maksud adalah path lengkap ke file, misalnya: /users/myuser/projects/lessproject/icon.svg.

Sepertinya dengan absolut yang Anda maksud adalah absolute-url function _pre-resolves_ path relatif yang diteruskan ke path output penuh, berdasarkan lokasi file di mana fungsi absolute-url dipanggil, relatif terhadap lokasi tempat file CSS keluaran yang dikompilasi akan disimpan.

Yaitu kalian berdua memiliki arti yang sama. Seperti yang saya lakukan, pada saat itu.

ke jalur keluaran lengkap, berdasarkan lokasi file tempat fungsi absolut-url dipanggil, relatif terhadap lokasi tempat file CSS keluaran yang dikompilasi akan pergi.

Seperti, menulis ulang URL atau jalur root masih akan berlaku, tetapi berdasarkan lokasi definisi? Itu tampaknya sedikit berbeda dari contoh asli @lukeapage , yang tidak berbicara tentang URL relatif terhadap keluaran, tetapi URL _ selama kompilasi_; misalnya lokasi data-uri() .

Jadi masalah ini agak sulit dilacak karena orang telah memposting tentang masalah yang serupa, tetapi tidak persis sama. Artinya, mengubah _source_ relatif mungkin memerlukan solusi yang jauh berbeda daripada mengubah _output_ relatif. Atau mungkin tidak; itu tergantung pada logika pathing; tetapi kita harus jelas bahwa data-uri tidak menghasilkan jalur apa pun sebagai keluaran.

Mungkin kita membutuhkan sesuatu seperti resolve() ? Entahlah, hanya spitballing, tapi url(resolve(file(), "my/path")) ? Saya rasa itulah yang dimaksud @ miljan-aleksic dengan absolute() , karena itu akan menghasilkan URL absolut. Tapi itu masih harus mengambil masukan (seperti file() , untuk mengatasi). Jika tidak, Anda dapat melakukan sesuatu seperti file-resolve() untuk menetapkan logika itu dalam satu fungsi, tetapi memiliki resolve() dan file() sebagai dua fungsi mungkin berguna secara terpisah.

Bagian rumit tentang semua ini adalah semua opsi URL penulisan ulang, yang sekarang ada lebih banyak dari gabungan PR yang menambahkan dukungan modul. (https://github.com/less/less.js/pull/3248). Jadi jika mengembalikan URL relatif file, apakah masih dapat ditulis ulang? Saya akan berasumsi ya, tapi kita harus jelas.

Ya, menyelesaikan () dan file () mendefinisikan dengan tepat apa yang saya coba jelaskan. Saya berharap kami dapat melihat ini diterapkan dalam waktu dekat.

@ miljan-aleksic Oke, itu masuk akal kalau begitu.

Sebenarnya, file() kurang tepat, karena itu akan mengembalikan nama file yang saya anggap, itu akan menjadi lebih seperti dir() . Dan itu mungkin harus berupa konstanta variabel per file.

Bagaimana dengan:

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

Jadi, dua hal ditambahkan: 1) sebuah fungsi resolusikan untuk menggabungkan jalur, 2) konstanta @DIR (dan @FILE ?) Dimasukkan ke dalam setiap file saat mengevaluasi. Satu-satunya hal rumit tentang itu adalah pengujian bahwa vars yang diinjeksi tidak menimpa atau digabungkan dengan vars lain di root, tetapi itu seharusnya cukup mudah untuk diuji. Atau haruskah mereka huruf kecil, seperti @arguments ? Dalam hal ini, saya akan menyarankan @directory dan @filename untuk menghindari konflik. Apa pilihan paling Less-y?

Mungkin kita membutuhkan sesuatu seperti resolve() ?

^ Bingo. Tepat sekali.

Apa pilihan paling Less-y?

Saya akan memilih opsi Node.js-y: __dirname
Itu sudah ada sejak lama dan terkenal. Menggunakan nama yang sama untuk konsep yang sama di Less mungkin merupakan ide yang bagus.

Saya akan memilih opsi Node.js-y: __dirname

Err ... itu tidak akan cocok dengan kata kunci Less / CSS atau variabel Less atau semantik fungsi. Kami harus melakukan yang lebih baik dari itu. @__dirname mungkin, tetapi garis bawahnya masih agak aneh untuk bahasanya. Tidak cocok sama sekali.

garis bawah masih agak aneh untuk bahasanya. Tidak cocok sama sekali.

Garis bawah di depan ganda digunakan untuk menunjukkan 'sesuatu yang disediakan sistem' dalam banyak bahasa, terutama ketika berhubungan dengan hal-hal seperti variabel intrinsik. Jadi out-of-placeness adalah inti masalahnya.

Tentu saja; jika Anda tidak menyukainya, Anda selalu bisa menggunakan turunan seperti @dirname atau @dir-name .

Namun, setelah memikirkan hal ini lagi, mengapa kita bahkan _membutuhkan_ jalur file saat ini yang diekspos sebagai variabel? Tidak dapatkah itu dijalin ke dalam fungsi konseptual resolve() itu sendiri?

Tidak dapatkah itu dijalin ke dalam fungsi konseptual resol () itu sendiri?

Dan kami kembali ke proposal saya, hanya dengan nama fungsi yang berbeda. Saya masih paling menyukainya, bahkan lebih baik sebagai tekad ().

Dan kami kembali ke proposal saya, hanya dengan nama fungsi yang berbeda.

Semacam.

Apa yang saya maksud adalah bahwa afaik tidak perlu meneruskan URL / path file yang menahan panggilan ke fungsi resolve() , karena lokasi itu harus _known_ ke fungsi tersebut.

this di dalam fungsi mengacu pada instance FunctionCaller , yang memiliki properti currentFileInfo .
Properti itu diinisialisasi ke info file dari Call AST Node yang sesuai dengan pemanggilan fungsi.
Yaitu

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

Jika saya membaca kode dengan benar, info file di sana sesuai dengan info file tempat pemanggilan fungsi adalah _declared_ - bukan file tempat pemanggilan fungsi dievaluasi.

Itu berarti tidak masalah menggunakan info file ini untuk resolver URL yang 'bersemangat'. Ini akan bertindak seperti yang diharapkan, bahkan jika panggilan fungsi ditempatkan di dalam mixin yang diimpor dan dievaluasi dalam konteks file lain. Yaitu: dengan resolusi yang disematkan ke file tempat mixin didefinisikan.

Namun, setelah memikirkan hal ini lagi, mengapa kita bahkan membutuhkan jalur file saat ini yang diekspos sebagai variabel? Tidak dapatkah itu dijalin ke dalam fungsi konseptual resol () itu sendiri?

Jika kami yakin tidak ada yang membutuhkan file saat ini atau fungsi resolver umum ... mungkin ... masalahnya adalah var lokal eksplisit menjelaskan bahwa ini bukan fungsi generik, dan bahwa fungsi tersebut tidak akan dievaluasi seperti fungsi lainnya. Itu perhatian saya yang sebenarnya, adalah semantik. Apa pun nama Anda, jika Anda tidak memiliki "penanda" khusus untuk "file saat ini", itu tidak seperti fungsi lain yang diselesaikan dengan cara yang sama berdasarkan masukan. Dengan kata lain, ini adalah fungsi yang menyelesaikan menurut masukan yang tidak terlihat, dan itu menjadi perhatian saya. Namun, jika fungsinya adalah sesuatu yang sangat eksplisit seperti current-file-resolve() , mungkin itu sudah cukup jelas. Jika tidak, Anda hanya akan membingungkan orang mengapa panggilan mixin tidak menyelesaikan specialfunction() sesuai dengan file yang dipanggil, alih-alih file tempat mixin didefinisikan.

Jadi, tidak, var lokal secara teknis tidak _needed_, tetapi arti / output / perilaku harus jelas dari semantiknya.

hmm ...

Baik. Lalu bagaimana kalau kita memiliki fungsi resolve-url(url, [base]) - dengan opsional base ; default ke direktori file di mana panggilan fungsi ditulis / dideklarasikan / didefinisikan. Kemudian miliki fungsi declared-dir() yang hanya menarik this.fileInfo dan mengambil path, jika penulis ingin menarik path secara eksplisit; ingin mengambil jalur dari file yang berbeda; atau perlu menggunakan ini sebagai bagian dari beberapa fitur lain yang tidak terkait dengan resolusi URL.

Yaitu panggilan bentuk penuh (tanpa basis implisit) akan menjadi seperti:

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

... dan akan setara dengan hanya melakukan

resolve-url("../foo")

... yang setara dengan orang malas

url("../foo")

Tidak ada variabel yang dimasukkan secara 'otomatis' yang dibutuhkan dengan cara itu. Ini bisa diimplementasikan murni sebagai satu set fungsi plugin, menurut saya. Dan satu-satunya mekanik inti yang kita perlukan adalah cara untuk menandai URL sebagai 'sudah diselesaikan', sehingga logika resolver default dapat diblokir agar tidak berjalan pada URL yang keluar dari fungsi resolve-url .

Semantik harus dijelaskan dalam dokumentasi kursus. Dan dokumentasi itu secara eksplisit dapat membandingkan url dengan resolve-url untuk menggambarkan evaluasi / resolusi yang bersemangat dan malas.

_{Untuk berjaga-jaga jika ide "variabel yang dimasukkan" tidak akan berfungsi (tanpa peretasan tambahan) karena file yang diimpor memiliki cakupan yang sama.}

<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";

Berbicara tentang implementasi berbasis fungsi, saya pikir (tetapi tidak bisa memastikan) bahwa masih mungkin untuk mendapatkan jalur file di mana fungsi tersebut dipanggil di suatu tempat di this.context.? atau this.context.frames[?] atau lebih.

emmmm, jadi kami tidak punya cara yang lebih baik untuk mengatasinya?

@bayu_joo
emmmm, jadi kami tidak punya cara yang lebih baik untuk mengatasinya?

Evaluasi yang malas membuat ini sangat sulit untuk diselesaikan dengan benar, saya khawatir.

@ tujuh-fase-maks
Berbicara tentang implementasi berbasis fungsi, saya pikir (tetapi tidak bisa memastikan) bahwa masih mungkin untuk mendapatkan jalur file di mana fungsi tersebut dipanggil di suatu tempat di this.context.? atau this.context.frames[?] atau lebih.

Anda harus dapat menemukan node Call dalam hierarki, ya.