Fable: 소스 맵 지원 다시 가져오기

Fable 3는 더 이상 fable-compiler 패키지( fable-loader 와 함께 사용됨)를 통해 배포되지 않습니까? 😱 순수 Fable 앱이 node.js 앱을 만들기 위해 Fable-splitter보다 더 나은 사용자 경험을 제공하지만 npm 배포판을 제거하는 것은 모든 곳에서 큰 변화가 될 것이며 솔직히 템플릿, 라이브러리와 같이 작업하는 데 약간의 고통이 될 것이라는 점을 이해합니다. 및 프로젝트. npm upgrade fable-compiler 라고 말하는 것이 훨씬 더 쉽습니다.

로컬 도구의 버전 고정을 수정했기 때문에 다른 모든 F# 도구(Paket, Fake, Fantomas, Femto, Snowflaqe)와 마찬가지로 Fable 3를 dotnet 도구로 배포하는 것이 좋습니다. Fable-compiler를 병렬 배포로 유지하는 것은 명확한 컷을 갖는 것보다 사용자에게 더 혼란스러울 것입니다.

사람들이 Fable을 dotnet 도구로 호출하는 데 익숙해지면 더 좋겠지만 😸 하지만... 모든 자습서, 프로젝트, 템플릿을 업데이트하는 것이 고통스럽다는 것을 이해합니다(과거와 마찬가지로). 따라서 우리는 Fable dotnet 도구를 호출하는 새로운 fable-loader 주 버전을 출시하는 것을 고려할 수 있습니다. 업그레이드 단계(안정된 버전이 릴리스된 경우)는 다음과 같습니다.

dotnet tool install fable
npm upgrade fable-loader

아마도 *.fs.js 를 .gitignore에 추가할 것입니다. fable-compiler 는 제거할 수 있는지 여부, 호출되지 않을 뿐입니다. 어떻게 보일까요? 그리고 누군가가 새로운 페이블 로더를 유지하기 위해 자원할 것인가? 😉

Fable-compiler를 병렬 배포로 유지하는 것은 명확한 컷을 갖는 것보다 사용자에게 더 혼란스러울 것입니다.

최소한의 변경으로 이전 버전과의 호환성을 유지하는 것은 정말 중요하며 많은 사람들을 기쁘게 할 것입니다. 지금은 간접 참조(fable이 먼저 호출된 다음 webpack이 호출됨)의 수준 때문에 다운그레이드처럼 들리며 webpack은 Fable이 파일을 컴파일한 후에만 파일이 존재할 것으로 예상하지만 지금은 완전히 _invisible_이고 매우 비슷하게 보입니다. TypeScript가 기존 프로젝트와 통합되는 방법.

나는 Fable-splitter를 사용하는 대신 node.js 애플리케이션의 구축 및 실행을 단순화하는 CLI 도구를 좋아합니다.

로컬 도구의 버전 고정을 수정했기 때문에 Fable 3를 dotnet 도구로 배포하는 것이 좋습니다.

기존 사용자에게 어떤 것을 선호하는지 묻는 설문조사(예: Twitter에서)를 만드는 것이 아이디어일 수 있습니까?

이 문제는 소스 맵에 관한 것이며 기여자에게 혼란을 줄 수 있으므로 토론을 #2195로 이동합니다.

소스 맵이 없으면 launch.json 를 통해 VSCode에서 단계별 디버깅과 통합할 수 없습니다. 맞습니까?

나는 대부분의 프론트 엔드 사용자가 어쨌든 시간 여행 디버거를 사용하는 것을 선호할 것이라고 생각합니다.

VSCode 디버거를 계속 사용할 수 있지만 중단점은 생성된 JS 파일에서만 적중될 수 있습니다. 나는 VSCode와 Chrome 모두에서 소스 맵을 자주 사용했지만(때로는 이름 맹글링으로 인해 값을 식별하기 어려웠지만 Nagareyama에서 개선하려고 노력하고 있음) 다른 많은 사용자가 그랬는지 모르겠습니다.

아직 이에 대한 코드를 시작하지 않았지만 계속 주시하고 있습니다. 내 첫 번째 성향은 이것이 정확히 필요한 것이라고 가정하고 mozilla/source-map 의 직접 포트를 수행하는 것이지만 포트에 대해 C# 또는 F#을 사용하는 것이 더 나은지 궁금합니다. F#으로 직접 작성하지만 C#을 선택하면 몇 가지 이점이 있습니다. 어느 쪽이든 라이브러리를 이식하면 일반적으로 .NET 에코시스템에 유용한 소스 맵 작업을 위한 기본 .NET 구현이 제공됩니다. 지금은 제한된 여가 시간에 이 옵션을 사용하려는 의도로 프로젝트 를

방금 나에게 일어난 또 다른 옵션은 mozilla/source-map 라이브러리에 대한 WebAssembly 지원을 사용하여 WebAssembly로 컴파일한 다음 Wasmtime을 사용하여 WASM을 .NET 라이브러리에 포함하는 것 입니다. 나는 이 옵션에 익숙하지 않지만 그것이 작동하고 합리적으로 수행된다면 Javascript의 원본 소스 맵 라이브러리와 동기화된 구현을 유지하는 더 쉬운 방법일 수 있습니다.

방금 나에게 일어난 또 다른 옵션은 mozilla/source-map 라이브러리에 대한 WebAssembly 지원을 사용하여 WebAssembly로 컴파일한 다음 Wasmtime을 사용하여 WASM을 .NET 라이브러리에 포함하는 것 입니다. 나는 이 옵션에 익숙하지 않지만 그것이 작동하고 합리적으로 수행된다면 Javascript의 원본 소스 맵 라이브러리와 동기화된 구현을 유지하는 더 쉬운 방법일 수 있습니다.

F# 변환기에 Java 스크립트가 필요한 것처럼 들립니다... 🤷

진지하게 말하자면 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.join , util.relative 과 같은 "util.js" 기능에 대한 도움이 필요할 수 있습니다. source-map-generator.js 에서 사용되는

F# 유형 안전 때문에 util.getArg 가 필요하지 않을 것이라고 거의 확신하고, '__proto__' 관련 버그를 피하기 위한 해킹이기 때문에 util.toSetString 가 필요하지 않을 것이라고 거의 확신합니다.

CLI로 사용할 것인지 아니면 ... ?

@delneg 감사합니다! 주말에 살펴보고 해당 기능을 홍보하려고 합니다.+1: 예, 라이브러리는 Fable.Cli에서 사용됩니다. 독립 라이브러리로 게시하면 Nuget 패키지를 참조할 수 있습니다.

SourceMapNode, SourceMapGenerator의 대부분을 수행했으며 현재 진행 상황을 보여주기 위해 README.md를 만들었습니다.
또한 ATM에서 어떤 도움이 필요한지 찾을 수 있습니다.

https://github.com/mozilla/source-map#generating -a-source-map 문서에 따르면 현재 우리가 가지고 있는 것은 소스 맵을 생성하기에 충분합니다... ATM)

이것은 환상적인 @delneg입니다! 빠른 시도를 했고 작동하는 것 같습니다. +1: 이제 디버깅을 활성화하려고 합니다.

좋습니다. 다음 단계를 제안할 수 있습니까?
즉, 너겟 게시 또는 테스트 작성 또는 다른 것(리포지토리의 README에서 가져온 것일 수 있음)
(추신 비록 나는 너겟 퍼블리싱을 해본 적이 없고 아마도 우화 계정을 사용해서 해야 할 것입니다)
PPS가 바로 작동하는 것은 당연합니다. F#을 사용하는 동안 익숙해졌습니다.

다음 단계는 소스맵이 실제로 디버깅을 위해 작동하는지 테스트하고 Fable에서 추가 작업을 수행해야 합니다( --sourceMap 옵션 추가, 파일에 저장`. 제가 직접 할 수 있습니다. 또한 PR도 보낼 것입니다) (명시적 옵션 대신 선택적 인수를 사용하는 것과 같이) 약간의 API를 연마합니다.

지금 우리는 Fable Nuget 계정이 없으며 만일을 대비하여 개인 계정과 보통 2-3명의 소유자로 패키지를 게시하고 있습니다. nuget.org에서 계정을 만들고 토큰을 생성하면 게시를 쉽게 자동화할 수 있습니다. 스크립트를 홍보할 수 있습니다. 원하는 경우 패키지의 공동 작업자로 나를 추가할 수도 있습니다.

좋아, 시간이 나면 너겟 퍼블리싱을 확인해볼게
또한 저장소에 공동 작업자로 추가했습니다.
가능하다면 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 관련 사례(나는 atm을 하지 않을 것임)에서만 사용된다고 생각하므로 실제로 지금 당장은 필요하지 않습니다.

추신 SourceNode 등에 관해서 - 제 생각에는 우리가 sourcemap의 .net 포트를 하고 있다면 있는 모든 것을 제대로 구현하도록 합시다. 지금은 사용하지 않더라도 1~2년 후에 필요할 수도 있습니다.

.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로 변경하고 잠재적인 netstandard2.0 사용자를 위해 README에 메모를 남길 것입니다.
2.0에서 작동하는 데 필요한 사람이 있으면 Stackoverflow의 대체 솔루션이 제공됩니다.

편집: 업로드된 1.0.1 https://www.nuget.org/packages/source-map-sharp/1.0.1 with netstandard2.1

또 다른 옵션은 다중 대상 지정을 통해 GetRelativePath에 의존하는 항목을 조건부로 제외(#if 사용)하여 다른 모든 항목을 .Net 표준 2.0에서 사용할 수 있도록 하는 것입니다.

또 다른 옵션은 다중 대상 지정을 통해 GetRelativePath에 의존하는 항목을 조건부로 제외(#if 사용)하여 다른 모든 항목을 .Net 표준 2.0에서 사용할 수 있도록 하는 것입니다.

간단한 상대 URL의 문제에 대한 과도한 복잡성처럼 보입니다( GetRelativePath가 필요한 atm만 해당).

dotnet 도구로서의 Fable은 netcoreapp3.1이므로 netstandard2.1을 대상으로 하는 것이 좋습니다. Path.GetRelativePath(path, pathTo).Replace('\\', '/') 와 같이 Windows에서 실행할 때 경로를 정규화해야 할 수도 있습니다.

@jwosty가 지적한 대로 최대 호환성을 위해 라이브러리가 netstandard2.0을 대상으로 하도록 하려면 실제로 자체 구현이 있습니다. 나는 한 동안 그것을 손도 안하지만 잘 작동 것 같다 : 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) 토론을 source-map-sharp 저장소 문제로 마이그레이션해야 할까요?
2) 우리는 이 프로젝트를 위해 일종의 WASM 컴파일을 사용할 계획입니까?
3) Fable이 source-map-sharp를 사용하기 시작하는 데 필요한 다른 것이 있습니까(문서, 테스트, 추가 API 등 포함).

편집: 좋습니다. 이미 사용자 정의 Util.getRelativePath를 추가하고 테스트를 추가했으며 약간의 수정 후에는 녹색이 되었습니다.
그런 다음 netstandard2.0으로 돌아가거나 1.0.2 너겟을 게시해야 합니까?

대단하다 @delneg! 👏 🚀 👏

1. 예, 토론을 source-map-sharp 저장소로 이동하는 것이 합리적입니다. +1: 알림을 받을 수 있도록 제 입력이 필요할 때 저를 언급해 주세요.
2. 원본 소스 맵에서 WASM 사용을 확인하지 않았지만 숫자 계산 속도를 높이기 위해 WASM을 지원하는 환경에서 사용한다고 가정합니다. .NET 포트에서는 걱정할 필요가 없다고 생각합니다.
3. 괜찮을 거에요. 요즘 시간이 별로 없었어요. 하지만 곧 소스 맵과 함께 3.1 베타 릴리스를 게시하려고 합니다. 💪 1.0.2를 게시하여 베타에서 사용할 수 있습니다.

@delneg의 환상적인 작업 덕분에 Fable 3.1 베타가 소스 맵 지원과 함께 게시되었습니다! :타다: 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.

지원해 주셔서 감사합니다.
앞으로 source-map-sharp를 유지하기 위해 최선을 다할 것이며 지금 작동하게 되어 기쁩니다.
1) 그러면 repo의 이슈에 글을 쓰겠습니다. 그리고 누군가 질문이 있는 경우 등 - source-map-sharp에서 이슈를 열어주세요.
2) 예, 성능을 향상시키기 위해 WASM을 사용했다고 가정합니다.
WASM 버전의 source-map-sharp 작동을 시도했지만 .net의 WASM 컴파일 상태가 끔찍하고 사용하기 매우 어려운 것 같습니다(일부 작업은 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 리포지토리를 가리켰습니다. 또 잘했어!