LivelyKernel / lively.next

lively.next is a personal programming kit. It emphasizes liveness, directness, and interactivity.
https://lively-next.org
MIT License
69 stars 16 forks source link

Generate source maps for transformed code and kill babel #316

Open merryman opened 3 years ago

merryman commented 3 years ago

Basically this is a import sourceMap from 'https://jspm.dev/source-map' and start from there by including proper calls to SourceMapGenerator objects within the lively.source-transform predominantly. This will have an impact on our compilation time and should be an optional thing, but I feel like this may be worth it by now. Debugging from the browser would become quite a bit more accessible for many.

https://github.com/mozilla/source-map

I am also thinking about removing babel from the development environment and solely using it when freezing parts for production deployment. The rational is that babel is a big impact on compilation performance that we mostly dont need since browser vendors have been quite good at catching up with the evolution of ECMAScript afaik.

In case we remove babel, that simplifies our sourcemap generation somewhat. If we keep it, we will need to figure out a way to combine the sourcemaps generated from babel with our custom ones. That requires some mixing of SourceMapConsumer and SourceMapGenerator I guess.

Edit: The only actual reason for sticking with babel is that we still need it to transpile ESM module syntax to systemjs module format. However this can also be achieved by other compilers such as https://github.com/swc-project/swc. SWC has an effective payload of 3.5mb and basically zero npm package dependencies. Its suffices to fetch the precompiled wasm binary to get it running. Could speed up our total install time by a lot.

merryman commented 11 months ago

There is a new case for this, especially since the introduction of fast load. #1038 Since it now has become increasingly hard to debug the code when execution is spread across bundled code, it would be worthwhile to provide source maps, at least with regards to the fast-load bundles. This would require us to ramp up the freezer, such that it also creates source maps alongside the source code transformations.

merryman commented 11 months ago

Alongside enhancing the source transform to handle source maps, we should also get rid of babel and all of the dependencies alongside it, since modern browser basically support everything syntactically we require.

merryman commented 4 months ago

Another interesting option is to make the custom source transformation operate around magic-string. That way get can generate a source map on the fly as part of our general source transformations. That would only require an upgrade to the visitors to operate on a string instead.

linusha commented 4 months ago

We should also keep recast in mind as an option, as it operates on ASTs directly, similar to our source transformations.