Less.js: Использование bin / lessc выбрасывает «Путь должен быть строкой. Получено не определено»

Созданный на 10 мая 2016  ·  12Комментарии  ·  Источник: less/less.js

Как уже сообщалось в # 2881 и после слияния # 2891, запуск lessc --source-map-map-inline styles/main.less в узле v6 выдает

TypeError: Path must be a string. Received undefined
    at assertPath (path.js:7:11)
    at Object.basename (path.js:1355:5)
    at /Users/jhnns/dev/jhnns/less.js/bin/lessc:311:61
    at Object.<anonymous> (/Users/jhnns/dev/jhnns/less.js/bin/lessc:508:3)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:456:32)
    at tryModuleLoad (module.js:415:12)
    at Function.Module._load (module.js:407:3)

Это потому, что неопределенный путь передается как basename .

bug low priority up-for-grabs

Самый полезный комментарий

Хотите знать о статусе этого? Я получаю эту ошибку на узле 6/7.

Все 12 Комментарий

какие-нибудь обновления по этому поводу?

да какие обновления?
Я бы хотел перейти на узел @ 6 сейчас, это LTS, но я не могу, пока это не будет исправлено

Хотите знать о статусе этого? Я получаю эту ошибку на узле 6/7.

Я тоже получаю эту ошибку ..
Как я могу скомпилировать мой less с отдельным файлом карты?
Я использую команду:
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 совершенно не имеет значения

Не совсем так, в исходной карте есть поле file указывающее на выходной CSS (хотя я вижу, что это необязательно в последних версиях спецификаций).

В любом случае, насколько я могу судить, проблема именно в этой части . Таким образом, это просто вопрос замены каталога вывода css любым каталогом (каталог исходной карты?), Если output не определен.
Что ж, PR приветствуются (лично я не использую исходные карты и понятия не имею, какие варианты могут быть нарушены этими изменениями для дальнейшего тестирования).

Поддержка внешних исходных карт вместе с трубопроводом не имеет функциональной ценности. Это только дает пользователям * nix соглашение о передаче файла по конвейеру, вместо того, чтобы указывать фактический выходной параметр.

Нет смысла генерировать внешнюю исходную карту, а затем направлять выходной CSS в следующую операцию.

Конвейер подразумевает дальнейшие изменения, происходящие на следующем шаге (шагах) цепочки, или использование CSS (и исходной карты) для обслуживания приложением веб-сервера на последнем шаге.

Любые изменения вывода CSS со стороны Less сделают недействительной исходную карту, созданную Less. Чтобы сделать исходную карту снова действительной, вам нужно будет отслеживать эти изменения в другой исходной карте, а затем объединить ее с исходным выводом Less, чтобы создать составную исходную карту, которая восстанавливает сопоставление с правильным содержимым в исходных файлах .less .

Все, что находится дальше в цепочке конвейерных операций, больше не будет иметь ссылки на внешнюю исходную карту, потому что оно не отправляется в конвейер. Таким образом, он не может этого сделать, и вы всегда застреваете с неработающей исходной картой.

И, конечно же; если последний шаг цепочки предназначен для обслуживания скомпилированного css и исходной карты: та же проблема. Никакой ссылки на карту. (Как вы собираетесь обслуживать оба файла в качестве ответа на один запрос? Встраивание исходной карты? Тогда почему бы не скомпилировать файл less с помощью встроенной карты для начала?)

Я бы предпочел ясность и руководство пользователя (например, «падение в яму успеха»), запрещающее комбинацию операций, которая может привести только к проблемам с нарушением сгенерированных артефактов.

Поддержка внешних исходных карт вместе с трубопроводом не имеет функциональной ценности. Это только дает пользователям * nix соглашение о передаче файла по конвейеру, вместо того, чтобы указывать фактический выходной параметр.

Согласовано. Если необходимо указать имя выходного файла, его следует указать в качестве аргумента для компилятора lessc .

Тем не менее, документировались ли трубопроводы в прошлом? Если нет, то это спорный вопрос, и мы можем просто задокументировать текущее поведение. Если это так, то нам необходимо задокументировать прошлое и неподдерживаемое в настоящее время поведение.

Тем не менее, документировались ли трубопроводы в прошлом?

Конвейер работает путем перенаправления потоков, таких как stdout или stderr. Когда lessc не указано имя выходного файла, он выводится в стандартный вывод. В этом смысле трубопроводы всегда официально поддерживались и должны поддерживаться и впредь. Вы, вероятно, нарушили бы множество разумных сценариев использования, иначе люди, которые полагаются на каналы для передачи точно в срок скомпилированных меньшего количества файлов, любому серверному приложению, необходимому для обслуживания их как CSS.

Если вы хотите использовать конвейер вместе с исходной картой, это все еще возможно в разумных пределах:
вам нужно будет сделать его встроенной исходной картой, а затем полагаться на дальнейшие шаги обработки в конвейере для декодирования встроенной карты; объединять в него модификации; и повторно применять его как встроенную карту исходного кода всякий раз, когда эти шаги дополнительно изменяют CSS, который был скомпилирован компилятором lessc.

Затем, если вам нужна внешняя исходная карта для повышения производительности - т. Е. Избегая дополнительных байтов встроенной карты, доставляемой всем посетителям. - последний шаг в конвейере должен отключить встроенную карту исходного кода и вывести два файла: файл css и файл карты.

Нет смысла генерировать внешнюю исходную карту, а затем направлять выходной CSS в следующую операцию.

Конвейер подразумевает дальнейшие изменения, происходящие на следующем шаге (шагах) цепочки, или использование CSS (и исходной карты) для обслуживания приложением веб-сервера на последнем шаге.

Я не согласен с приведенным мнением и считаю неверным предполагать, что находится по ту сторону какой-либо конкретной трубы. Что делать, если труба куда-то загружается? Что, если конвейер обслуживает результирующий CSS, но клиенту не всегда нужна карта источников?

Поскольку реализован флаг --source-map-url , я считаю, что этот вариант использования следует поддерживать.

В любом случае пользователи не должны видеть непонятные неперехваченные ошибки, особенно при передаче флагов из текста справки.

Только мои 2 цента после того, как я был заблокирован этой проблемой.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги