-
Notifications
You must be signed in to change notification settings - Fork 295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring back source map support #2166
Comments
Will Fable 3 no longer be distributed via the |
Since they fixed the version-pinning of local tools, distributing Fable 3 as a dotnet tool is likely the way to go, as all the other F# tools are doing (Paket, Fake, Fantomas, Femto, Snowflaqe). Keeping fable-compiler as a parallel distribution will probably be more confusing to the users than having a clear cut. I would prefer if people got used to call Fable as a dotnet tool 😸 But... I do understand that updating all tutorials, projects, templates is a pain (as it's been in the past). So we could consider to release a new fable-loader major version that just invokes the Fable dotnet tool. The steps to upgrade (when stable versions are release) would then just be:
Probably also adding |
Keeping backward-compatibility with the least changes required is really important and would make many people happy. Right now, it sounds more like a downgrade because of the level of indirection introduced (fable has be called first, then webpack) and webpack will expect files to exist only after Fable compiled them whereas right now it is totally invisible and looks a lot like how TypeScript is integrated with existing projects. I do like the CLI tool to simplify building and running node.js applications instead of using fable-splitter
Maybe it is an idea to make a poll (on twitter for example) to ask existing users what they would prefer? |
Moving the discussion to #2195 as this issue is about the source maps and it can be confusing for contributors. |
Without source maps there will be no way to integrate with step-by-step debugging in VSCode via I'm guessing most front-end users will prefer using a time-travelling debugger anyway. |
You can still use the VSCode debugger but breakpoints can only be hit in the generated JS files. I did use the source maps frequently both in VSCode and Chrome (although sometimes name mangling made it difficult to identify values, something we're trying to improve in Nagareyama), but I don't know if many other users did. |
I haven't started any code yet on this but I'm keeping my eye on this. My first inclination is the do a direct port of mozilla/source-map assuming that this is precisely what is needed but then I'm wondering if we'd be better to go with C# or F# for the port, I'd prefer to write it in F# myself but there is some benefits in choosing C#. Either way porting the library would provide a native .NET implementation for working with source-maps in general which may be a useful thing for the .NET ecosystem. For now I've forked the project with some intent of giving this option a shot in my limited spare time. Another option perhaps that just occurred to me would be to use WebAssembly support for mozilla/source-map library to compile to WebAssembly and then embed the WASM into a .NET library using Wasmtime. I'm not that familiar with this option but if it works and performs reasonably it may be an easier way to keep the implementation in sync with the original source-maps library in Javascript. |
Almost sounds like we need a Java-script to F# transpiler... 🤷 In all seriousness, an F# source map library would be a good idea. |
https://github.com/delneg/source-map-sharp |
This is great @delneg, thanks a lot! I think a direct translation works best even if it's not F# idiomatic in case we need to sync updates of the original library later 👍 |
I've done some work (here https://github.com/delneg/source-map-sharp), but I might need help with the "util.js" functions such as I almost sure we won't need Please also tell me if we'll be using that as a CLI or ... ? |
Thanks @delneg! I will have a look over the weekend and I'll try to PR those functions 👍 Yes, the library will be used from Fable.Cli. If you publish it as an independent library we can just reference your Nuget package. |
I've done most of SourceMapNode, SourceMapGenerator, and created a README.md to showcase the current progress. According to the docs here https://github.com/mozilla/source-map#generating-a-source-map , what we have now is sufficient to generate source maps ... (altough, i'm not entirely sure how atm) |
This is fantastic @delneg! I gave it a quick try and seems to be working 👍 I will now try to enable debugging. |
That's nice, can you propose the next steps ? |
Next steps should be testing that sourcemaps actually work for debugging and do the extra work in Fable (adding Right now we don't have a Fable Nuget account, we are publishing the packages with our personal account and usually 2-3 owners just in case. If you create an account in nuget.org and generate a token, it's easy to automate publishing. I can PR the script for that. You can also add me as collaborator of the package if you want. |
Ok, I'll check out nuget publishing stuff when i'll have time |
I've started adding more tests for SourceMapGenerator, they revealed some bugs that were hiding. |
https://www.nuget.org/packages/source-map-sharp/ |
This is great @delneg! Thanks a lot for this! I'm slowly getting back to work after the holidays so I'll try to push a Fable 3.1 beta release with source map support using your package when possible 👍 I think Fable itself doesn't need SourceNode but if you prefer it to add it for completeness it may help other consumers of the library. About |
Unfortunately, P.S. Regarding the SourceNode etc. - i think if we're doing a .net port of sourcemap, let's do it properly implementing all the stuff that there is, even if it's not used now it may be needed in a year or two |
.Net Standard 2.1 would leave Mono-related things in the dust (i.e. Xamarin things). But for the Fable use case that's probably fine as it's a development-only dependency and the framework doesn't really mean anything at runtime anyway. So if the library is only gonna be used in Fable, 2.1 is fine, but if you want maximum compatibility with other .Net stuff, 2.0 is more ideal for that. FWIW, someone provided a simple implementation of it on StackOverflow: https://stackoverflow.com/questions/275689/how-to-get-relative-path-from-absolute-path |
I think for now i'm gonna bump it to 2.1 then, and leave a note in README for potential netstandard2.0 users. Edit: uploaded 1.0.1 https://www.nuget.org/packages/source-map-sharp/1.0.1 with netstandard2.1 |
Another option would be to conditionally exclude (with #if) the things that rely on GetRelativePath via multitargeting, so that everything else would be available on .Net standard 2.0. |
Seems like an overcomplication for a simple relative URL's problem (atm only that requires GetRelativePath ) |
Fable as a dotnet tool is netcoreapp3.1 so it's ok to target netstandard2.1, just you may need to normalize the path when run in Windows like If you want the library to target netstandard2.0 for maximum compatibility as @jwosty points out, we actually have our own implementation. I haven't touched it in a while but it seems to work fine: Fable/src/Fable.Transforms/Global/Prelude.fs Lines 508 to 555 in ba509a9
|
Also
The period is probably needed for sourcemaps urls, so you may also need to do something like in the lines 545-548 of the excerpt above when normalizing the path. |
I'll check out the stuff above & adapt tests from JS (there's quite a bunch in test-util.js), probably will use our own implementation.
Edit: OK, that was easy, already added the custom Util.getRelativePath, added tests and after slight modifications they went green. |
Awesome @delneg! 👏 🚀 👏
|
Fable 3.1 beta is published with source map support thanks to @delneg fantastic work! 🎉 https://twitter.com/FableCompiler/status/1347421291502997504 |
Fantastic - from a Fable user: many thanks for this @delneg ! |
Amazing amazing amazing! |
Thanks for your support.
|
For anyone still not seeing the source maps after applying the instructions from @alfonsogarciacaro, try to clean your output files (including all the Other than that, thanks to everyone involved for bringing this great feature back 👍 |
Awesome work! I came back today to see if I could pick up on this project and to my delight it's already complete. I've archived the repo I had started scaffolding for this effort and pointed over to the https://github.com/delneg/source-map-sharp repo for now. Again great job! |
It's likely that Fable 3 will ship initially without F# source map support (we're trying to compensate that with more readable JS output) but the infrastructure to generate them is still in place. As Fable 3 is a "pure" dotnet app, we need a dotnet library to generate the source maps but we couldn't find any that meets our needs. The easiest way is probably to translate the sourcemap generator of Mozilla's JS library to dotnet (either F# or C#). It'd be great if the community could help with that.
The text was updated successfully, but these errors were encountered: