Less.js: Menggunakan bin / lessc melempar "Path harus berupa string. Diterima tidak terdefinisi"

ada pembaruan tentang ini?

ya, ada pembaruan?
Saya ingin pindah ke node @ 6 sekarang yaitu LTS tetapi saya tidak bisa sampai ini diperbaiki

Ingin tahu tentang status ini? Saya mendapatkan kesalahan ini dengan node 6/7.

Saya mendapatkan kesalahan ini juga ..
Bagaimana saya bisa mengkompilasi less saya dengan file peta terpisah?
Saya menggunakan perintah:
lessc --no-color test.less --source-map=test.css.map -source-map-url=test.css.map

Seperti yang disebutkan @jhnns , Ternyata itu mencari parameter ke-2 untuk output (ini tidak didokumentasikan), jadi ini gagal:

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

Namun menambahkan file output sebagai parameter alih-alih menyalurkannya berfungsi:

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

Semoga bisa membantu kalian 👍

Jadi, dengan kata lain, perbaikan yang tepat adalah "melempar kesalahan ketika file peta sumber ditentukan tetapi css keluarannya tidak", bukan?
Jelas karena peta sumber harus merujuk ke file css tertentu, tidak ada metode (non-vulgar) untuk menghasilkan peta sumber yang tepat tanpa output css yang ditentukan, yaitu baris perintah ini tidak masuk akal:

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

Tidak, itu harus bekerja seperti dulu - dua perintah itu:

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

Harus menampilkan ini sebagai baris terakhir:

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

Nama file keluaran CSS sama sekali tidak relevan, hanya tautan ke peta yang penting.

Nama file keluaran CSS sama sekali tidak relevan

Kurang tepat, peta sumber memiliki kolom file menunjuk ke output CSS (meskipun saya bisa melihatnya opsional dalam revisi spesifikasi terbaru).

Bagaimanapun, sejauh yang saya tahu masalahnya ada di bagian ini. Jadi, ini hanya masalah mengganti dir keluaran css dengan direktori apa pun (direktori sourcemap?) Jika output tidak ditentukan.
Yah, PR sangat baik (secara pribadi saya tidak menggunakan peta sumber dan tidak tahu opsi apa yang dapat dipatahkan oleh perubahan ini untuk diuji lebih lanjut).

Mendukung peta sumber eksternal bersama dengan perpipaan tidak menawarkan nilai fungsional. Ini hanya memberi pengguna * nix konvensi perpipaan ke file daripada menentukan parameter output yang sebenarnya.

Tidak masuk akal untuk membuat peta sumber eksternal dan kemudian menyalurkan css keluaran ke operasi lebih lanjut.

Perpipaan menyiratkan perubahan lebih lanjut yang terjadi pada langkah rantai berikutnya, atau CSS (dan peta sumber) yang digunakan untuk disajikan oleh aplikasi server web pada langkah terakhir.

Setiap perubahan pada keluaran CSS oleh Less akan membuat peta sumber yang dihasilkan Less tidak valid. Untuk membuat peta sumber valid lagi, Anda perlu melacak perubahan tersebut ke peta sumber lain dan kemudian menggabungkannya dengan satu keluaran asli dengan Less untuk membuat peta sumber gabungan yang memulihkan pemetaan ke konten yang benar dalam file .less asli .

Apa pun yang berada lebih jauh dalam rantai operasi perpipaan tidak akan memiliki referensi ke peta sumber eksternal lagi, karena tidak dikirim bersama ke dalam pipa. Karena itu tidak dapat melakukan ini dan Anda selalu terjebak dengan peta sumber yang rusak.

Dan tentu saja; jika langkah terakhir dari rantai dimaksudkan untuk menyajikan css yang telah dikompilasi dan peta sumber: masalah yang sama. Tidak ada referensi ke peta. (Bagaimana Anda akan menyajikan kedua file sebagai respons terhadap satu permintaan? Menyebariskan peta sumber? Lalu mengapa tidak mengkompilasi less dengan peta sebaris untuk memulai?)

Saya lebih suka kejelasan dan panduan pengguna (misalnya 'jatuh ke lubang kesuksesan') untuk tidak mengizinkan kombinasi operasi yang hanya dapat menyebabkan masalah dengan artefak yang dihasilkan rusak.

Mendukung peta sumber eksternal bersama dengan perpipaan tidak menawarkan nilai fungsional. Ini hanya memberi pengguna * nix konvensi perpipaan ke file daripada menentukan parameter output yang sebenarnya.

Sepakat. Jika nama file keluaran akan ditentukan, itu harus ditentukan sebagai argumen untuk lessc compiler.

Konon, apakah perpipaan didokumentasikan di masa lalu? Jika tidak, maka itu adalah poin yang diperdebatkan dan kami hanya dapat mendokumentasikan perilaku saat ini. Jika demikian, maka kita perlu mendokumentasikan perilaku masa lalu dan yang saat ini tidak didukung.

Konon, apakah perpipaan didokumentasikan di masa lalu?

Perpipaan bekerja dengan mengarahkan aliran seperti stdout atau stderr. Ketika lessc tidak diberi nama file keluaran, ia akan mengeluarkannya ke stdout. Dalam hal ini, perpipaan selalu didukung secara resmi dan harus terus didukung. Anda mungkin akan merusak banyak kasus penggunaan yang waras, sebaliknya untuk orang-orang yang mengandalkan pipa untuk berkomunikasi hanya dalam waktu yang dikompilasi lebih sedikit file ke aplikasi server apa pun yang perlu menyajikannya sebagai css.

Jika Anda ingin menggunakan perpipaan bersama dengan peta sumber, itu masih mungkin dengan cara yang masuk akal:
Anda harus membuatnya menjadi peta sumber sebaris dan kemudian mengandalkan langkah-langkah pemrosesan lebih lanjut dalam pipa untuk memecahkan kode peta sebaris; menggabungkan modifikasi ke dalamnya; dan menerapkannya kembali sebagai peta sumber sebaris setiap kali langkah-langkah tersebut memodifikasi lebih lanjut CSS yang telah dikompilasi oleh compiler lessc.

Kemudian, jika Anda menginginkan peta sumber eksternal demi kinerja - yaitu menghindari byte tambahan dari peta sebaris yang dikirimkan ke semua pengunjung. - langkah terakhir dalam pipeline harus memutus peta sumber sebaris dan mengeluarkan dua file: file css dan file peta.

Tidak masuk akal untuk membuat peta sumber eksternal dan kemudian menyalurkan css keluaran ke operasi lebih lanjut.

Perpipaan menyiratkan perubahan lebih lanjut yang terjadi pada langkah rantai berikutnya, atau CSS (dan peta sumber) yang digunakan untuk disajikan oleh aplikasi server web pada langkah terakhir.

Saya tidak setuju dengan sentimen yang dikutip, dan saya pikir tidak benar untuk mengasumsikan apa yang ada di sisi lain dari pipa tertentu. Bagaimana jika pipa diunggah ke suatu tempat? Bagaimana jika pipa melayani CSS yang dihasilkan, tetapi klien tidak selalu membutuhkan peta sumber?

Melihat flag --source-map-url diimplementasikan, saya yakin kasus penggunaan ini harus didukung.

Bagaimanapun, pengguna seharusnya tidak melihat kesalahan tak tertangkap yang tidak dapat dipahami, terutama saat meneruskan tanda dari teks bantuan.

Hanya 2 sen saya setelah diblokir oleh masalah ini.