Fable: Вернуть поддержку исходной карты

Будет ли Fable 3 больше распространяться через пакет fable-compiler (используется вместе с fable-loader )? 😱 Я понимаю, что чистое приложение Fable имеет лучший пользовательский интерфейс, чем fable-splitter, для создания приложений node.js, но удаление распределения npm было бы огромным изменением повсюду и, честно говоря, немного затруднительно для работы с: шаблонами, библиотеками и проекты. Просто ооочень проще сказать: npm upgrade fable-compiler и он будет готов к работе (надеюсь, без нарушения изменений)

Поскольку они исправили привязку версий локальных инструментов, распространение Fable 3 как инструмента dotnet, вероятно, будет правильным решением, как и все другие инструменты F # (Paket, Fake, Fantomas, Femto, Snowflaqe). Сохранение fable-compiler в качестве параллельного дистрибутива, вероятно, будет более запутанным для пользователей, чем четкое определение.

Я бы предпочел, чтобы люди привыкли называть Fable инструментом dotnet 😸 Но ... я понимаю, что обновление всех руководств, проектов, шаблонов - это боль (как и раньше). Таким образом, мы могли бы рассмотреть вопрос о выпуске новой основной версии загрузчика fable, которая просто запускает инструмент Fable dotnet. Шаги по обновлению (когда выпускаются стабильные версии) будут следующими:

dotnet tool install fable
npm upgrade fable-loader

Возможно также добавление *.fs.js в .gitignore. fable-compiler можно удалить или нет, он просто не будет вызван. Как бы это выглядело? И кто-нибудь вызвался бы поддерживать новый загрузчик басен? 😉

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

Сохранение обратной совместимости с минимальным количеством необходимых изменений действительно важно и сделает многих людей счастливыми. Прямо сейчас это больше похоже на понижение версии из-за введенного уровня косвенности (сначала вызывается fable, затем webpack), и webpack будет ожидать, что файлы будут существовать только после того, как Fable скомпилировал их, тогда как сейчас он полностью _invisible_ и очень похож на как TypeScript интегрируется с существующими проектами.

Мне нравится инструмент командной строки для упрощения сборки и запуска приложений node.js вместо использования fable-splitter.

Поскольку они исправили привязку версий локальных инструментов, распространение Fable 3 в качестве инструмента dotnet, вероятно, будет правильным решением.

Может быть, стоит провести опрос (например, в твиттере), чтобы спросить существующих пользователей, что они бы предпочли?

Перенос обсуждения на # 2195, поскольку этот вопрос касается исходных карт и может сбивать с толку участников.

Без исходных карт не будет возможности интегрироваться с пошаговой отладкой в ​​VSCode через launch.json , это правильно?

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

Вы по-прежнему можете использовать отладчик VSCode, но точки останова могут быть достигнуты только в сгенерированных файлах JS. Я часто использовал исходные карты как в VSCode, так и в Chrome (хотя иногда искажение имен затрудняло определение значений, что мы пытаемся улучшить в Нагарейяме), но я не знаю, делали ли это многие другие пользователи.

Я еще не начал писать код по этому поводу, но слежу за этим. Моя первая склонность - сделать прямой порт mozilla / source-map, предполагая, что это именно то, что нужно, но тогда мне интересно, лучше ли нам использовать C # или F # для порта, я бы предпочел сам напишу его на F #, но выбор C # дает некоторые преимущества. В любом случае перенос библиотеки предоставит собственную реализацию .NET для работы с исходными картами в целом, что может быть полезно для экосистемы .NET. На данный момент я развил проект с некоторым намерением попробовать эту опцию в мое ограниченное свободное время.

Другой вариант, который, возможно, только что пришел мне в голову, - использовать поддержку WebAssembly для библиотеки mozilla / source-map для компиляции в WebAssembly, а затем встроить WASM в библиотеку .NET с помощью Wasmtime . Я не очень знаком с этой опцией, но если она работает и работает разумно, это может быть более простой способ синхронизировать реализацию с исходной библиотекой исходных карт в Javascript.

Другой вариант, который, возможно, только что пришел мне в голову, - использовать поддержку WebAssembly для библиотеки mozilla / source-map для компиляции в WebAssembly, а затем встроить WASM в библиотеку .NET с помощью Wasmtime . Я не очень знаком с этой опцией, но если она работает и работает разумно, это может быть более простой способ синхронизировать реализацию с исходной библиотекой исходных карт в Javascript.

Похоже, нам нужен Java-скрипт для транспилятора F # ... 🤷

Если серьезно, библиотека исходных карт на F # была бы хорошей идеей.

https://github.com/delneg/source-map-sharp
Начата работа по переводу https://github.com/mozilla/source-map/blob/master/lib/source-map-generator.js
там совсем не лучший код но я попробовал сделать прямой перевод

Это отличный @delneg , большое спасибо! Я думаю, что прямой перевод работает лучше всего, даже если это не идиоматический F #, на случай, если нам понадобится синхронизировать обновления исходной библиотеки позже: +1:

Я проделал некоторую работу (здесь https://github.com/delneg/source-map-sharp), но мне может потребоваться помощь с функциями "util.js", такими как util.join , util.relative которые используются в source-map-generator.js

Я почти уверен, что нам не понадобится util.getArg из-за безопасности типа F #, и я почти уверен, что нам не понадобится util.toSetString потому что это способ избежать ошибок, связанных с '__proto __'.

Пожалуйста, также скажите мне, будем ли мы использовать это как интерфейс командной строки или ...?

Спасибо @delneg! Я посмотрю на выходных и постараюсь пиарить эти функции: +1: Да, библиотека будет использоваться из Fable.Cli. Если вы опубликуете его как независимую библиотеку, мы сможем просто сослаться на ваш пакет Nuget.

Я сделал большую часть SourceMapNode, SourceMapGenerator и создал README.md, чтобы продемонстрировать текущий прогресс.
Также вы можете узнать, какая помощь нужна в банкомате.

Согласно документам здесь https://github.com/mozilla/source-map#generating -a-source-map, того, что у нас есть сейчас, достаточно для создания исходных карт ... (хотя я не совсем уверен, как атм)

Это фантастика @delneg! Я быстро попробовал и, похоже, работает: +1: Сейчас я попробую включить отладку.

Приятно, не могли бы вы предложить следующие шаги?
Т.е. публикация nuget или написание тестов или что-то еще (может быть, что-то из README в репо)
(PS, хотя я никогда не публиковал nuget, и, вероятно, должен быть сделан с использованием учетной записи fable)
PPS не удивительно, что это сработало сразу, я к этому уже привык при использовании F #

Следующими шагами должно быть тестирование того, что исходные карты действительно работают для отладки и выполняют дополнительную работу в Fable (добавление опции --sourceMap , сохранение ее в файл`. Я могу сделать это на своей стороне. Я также пришлю вам PR чтобы немного улучшить API (например, использовать необязательные аргументы вместо явных параметров).

На данный момент у нас нет учетной записи Fable Nuget, мы публикуем пакеты с нашей личной учетной записью и обычно 2-3 владельцев на всякий случай. Если вы создадите учетную запись на nuget.org и сгенерируете токен, публикацию легко автоматизировать . Я могу пиарить сценарий для этого. Вы также можете добавить меня в качестве соавтора пакета, если хотите.

Хорошо, я проверю материалы публикации nuget, когда у меня будет время
Кроме того, я добавил вас в качестве соавтора в репо.
Если у меня получится, я тоже попробую немного отполировать API и попробую добавить несколько тестов для SourceGenerator.

Я начал добавлять больше тестов для SourceMapGenerator, они выявили некоторые скрытые ошибки.
Некоторые из них теперь исправлены, но раньше казалось, что все они должны быть исправлены - иначе сопоставления могут не работать в некоторых случаях.
Так что еще рано публиковать nuget atm
Если кто-то хочет помочь - посмотрите на провальные тесты ( dotnet test )

https://www.nuget.org/packages/source-map-sharp/
Я опубликовал пакет nuget, тесты для создания фактических сопоставлений, связанных с SourceMapGenerator (функция SerializeMapping), выполнены, и ошибки исправлены, поэтому он должен работать правильно.
Я продолжу работу над SourceNode и другими вещами, и было бы здорово, если бы some1 мог помочь с util.relative / util.join

Это здорово @delneg! Большое спасибо за это! Я медленно возвращаюсь к работе после праздников, поэтому я постараюсь выпустить бета-версию Fable 3.1 с поддержкой исходной карты, используя ваш пакет, когда это возможно: +1:

Я думаю, что самой Fable не нужен SourceNode, но если вы предпочитаете, чтобы он добавил его для полноты, это может помочь другим потребителям библиотеки. Что касается util.relative/join , я также попытаюсь отправить PR в ваш проект, но, учитывая, что он будет работать на .NET, я думаю, вы сможете использовать System.IO.Path.GetRelativePath и System.IO.Path.Combine : https://docs.microsoft.com/en-us/dotnet/api/system.io.path?view=net-5.0

К сожалению, GetRelativePath недоступен для netstandard2.0 (см. Https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getrelativepath?view=net-5.0#applies -к)
Решением может быть переход на netstandard2.1 (хотя я не знаю, хороший ли он)
Что касается util.join - после просмотра всех случаев, я считаю, что он используется только в случаях, связанных с consumer (которые я не буду делать в банкомате), так что на самом деле это не то, что нужно прямо сейчас.

PS Что касается SourceNode и т. Д. - я думаю, что если мы делаем порт .net для карты источников, давайте сделаем это правильно, реализуя все, что есть, даже если он не используется сейчас, он может понадобиться через год или два

.Net Standard 2.1 оставит вещи, связанные с Mono, в пыли (например, Xamarin). Но для варианта использования Fable это, вероятно, нормально, поскольку это зависимость, предназначенная только для разработки, и фреймворк в любом случае ничего не значит во время выполнения.

Так что, если библиотека будет использоваться только в Fable, подойдет версия 2.1, но если вам нужна максимальная совместимость с другими материалами .Net, лучше для этого подойдет версия 2.0.

FWIW, кто-то предоставил простую реализацию этого в StackOverflow: https://stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

.Net Standard 2.1 оставит вещи, связанные с Mono, в пыли (например, Xamarin). Но для варианта использования Fable это, вероятно, нормально, поскольку это зависимость, предназначенная только для разработки, и фреймворк в любом случае ничего не значит во время выполнения.

Так что, если библиотека будет использоваться только в Fable, подойдет версия 2.1, но если вам нужна максимальная совместимость с другими материалами .Net, лучше для этого подойдет версия 2.0.

FWIW, кто-то предоставил простую реализацию этого в StackOverflow: stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path

Я думаю, что сейчас я подниму его до 2.1 и оставлю заметку в README для потенциальных пользователей netstandard2.0.
Если кому-то это понадобится для работы под 2.0, у нас будет запасное решение от Stackoverflow.

Изменить: загружено 1.0.1 https://www.nuget.org/packages/source-map-sharp/1.0.1 с netstandard2.1

Другой вариант - условно исключить (с помощью #if) вещи, которые полагаются на GetRelativePath через многопользовательский режим, чтобы все остальное было доступно в стандарте .Net 2.0.

Другой вариант - условно исключить (с помощью #if) вещи, которые полагаются на GetRelativePath через многопользовательский режим, чтобы все остальное было доступно в стандарте .Net 2.0.

Похоже на чрезмерное усложнение для простой проблемы относительного URL (только для банкомата, для которого требуется GetRelativePath)

Fable как инструмент dotnet - это netcoreapp3.1, поэтому можно использовать netstandard2.1 для таргетинга, просто вам может потребоваться нормализовать путь при запуске в Windows, например Path.GetRelativePath(path, pathTo).Replace('\\', '/') .

Если вы хотите, чтобы библиотека была ориентирована на netstandard2.0 для максимальной совместимости, как указывает @jwosty , у нас действительно есть собственная реализация. Я давно к нему не прикасался, но вроде работает нормально: https://github.com/fable-compiler/Fable/blob/ba509a94a50522794d3e60f27dd826bb5602eca1/src/Fable.Transforms/Global/Prelude.fs#L508 -L555

Также Path.GetRelativePath не всегда добавляет точку перед относительным путем:

> Path.GetRelativePath("/foo/bar", "/foo/bar/hoho/mir");;
val it : string = "hoho\mir"

Период, вероятно, необходим для URL-адресов исходных карт, поэтому вам также может потребоваться сделать что-то вроде строк 545-548 отрывка выше при нормализации пути.

Я проверю материал выше и адаптирую тесты из JS (в test-util.js их довольно много), вероятно, буду использовать нашу собственную реализацию.
Также остается пара вопросов:
1) Может быть, нам стоит перенести обсуждение на вопросы репозитория, связанные с исходной картой?
2) Планируем ли мы использовать какую-либо компиляцию WASM для этого проекта (есть ли причина для этого, потому что я не знаю причину использования WASM в исходном репозитории карты исходных кодов)?
3) Есть ли что-нибудь еще, необходимое для Fable, чтобы начать использовать source-map-sharp, если что-нибудь вообще (включая документы, тесты, дополнительные API и т. Д.)

Изменить: ОК, это было легко, уже добавлен пользовательский Util.getRelativePath, добавлены тесты, и после небольших изменений они стали зелеными.
Должны ли мы тогда вернуться к netstandard2.0 и / или опубликовать 1.0.2 nuget?

Потрясающий @delneg! 👏 🚀 👏

1. Да, имеет смысл перенести обсуждение в репозиторий source-map-sharp: +1: Пожалуйста, упомяните меня, когда вам понадобится мой вклад, чтобы я получил уведомление.
2. Не проверял использование WASM в исходной карте источника, но я предполагаю, что они используют его в средах, поддерживающих WASM, для ускорения числовых вычислений. Я не думаю, что нам нужно беспокоиться об этом в порте .NET.
3. Все должно быть хорошо, у меня просто не было много времени в эти дни, но я постараюсь вскоре опубликовать бета-версию 3.1 с исходными картами 💪 Вы можете пойти дальше и опубликовать 1.0.2, поэтому мы используем это в бета-версии.

Бета-версия Fable 3.1 опубликована с поддержкой исходной карты благодаря фантастической работе @delneg ! : tada: https://twitter.com/FableCompiler/status/1347421291502997504

Фантастика - от пользователя Fable: большое спасибо за этот @delneg !

Удивительно, потрясающе, потрясающе!

Потрясающий @delneg! 👏 🚀 👏

1. Yes it makes sense to move discussion to source-map-sharp repository 👍 Please mention me when you need my input so I get the notification.

2. Didn't check WASM usage in original source-map, but I assume they use it in environments supporting WASM to speed up numeric calculations. I don't think we need to worry about it in the .NET port.

3. It should be fine, I just didn't have much time these days, but I'll try to publish a 3.1 beta release soon with source maps 💪 You can go ahead and publish 1.0.2 so we use this in the beta.

Спасибо за поддержку.
Я буду изо всех сил стараться поддерживать четкость исходной карты в будущем, и я рад, что сейчас это работает.
1) Я напишу в репо проблемы, и если у кого-то будут вопросы и т. Д. - пожалуйста, откройте проблему в source-map-sharp
2) Да, я полагаю, они использовали WASM для повышения производительности.
Я попробовал и получил WASM-версию работы с точным отображением исходного кода, однако состояние компиляции WASM в .net кажется ужасным и очень сложным в использовании (некоторая работа выполняется в проекте Uno.Platform.Bootstrap, но глядя на него исходный код меня очень разочаровал)
Поскольку source-map-sharp остается приложением .NET, если нам когда-нибудь понадобится повышенная производительность, мы всегда можем посмотреть на Span.и другие вещи .NET, чтобы сделать это быстрее
3) Я опубликовал версию 1.0.2 и увидел, что вы ее уже использовали, вот и все.
Я постараюсь продолжить публикацию Nuget в будущем, если мы обнаружим какие-либо ошибки и т. Д. (И постараюсь не менять API)

Для тех, кто все еще не видит исходные карты после применения инструкций от @alfonsogarciacaro , попробуйте очистить выходные файлы (включая все .fs.js ) и снова запустить сборку. Мне потребовалось время, чтобы понять это, потому что простое восстановление без очистки не помогло.

Кроме того, спасибо всем, кто вернул эту замечательную функцию 👍

Отличная работа! Я вернулся сегодня, чтобы посмотреть, смогу ли я заняться этим проектом, и, к моему удовольствию, он уже завершен. Я заархивировал репо, которое я начал строить для этих усилий, и пока указал на репозиторий https://github.com/delneg/source-map-sharp . Опять отличная работа!