LivelyKernel / LivelyKernel/lively.next
Generate source maps for transformed code and kill babel
- Dominant language
- JavaScript
- Stars
- 90
- Forks
- 20
- PR merge metrics
- No merged PRs in 30d
Description
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.
Contributor guide
Assessment
This issue has not been assessed yet.