EsModules #880
EsModules #880
Conversation
|
I can't understand the failing test on windows :-(. |
|
This seems to be easier than expected. I think this PR would actually be viable which was a surprise for me. If it were to get merged and it maintainers agreed, I'd try and follow it up with two more PRs
|
|
Thank you very much for working on this 🤩 |
|
@tgodzik Hi Tomasz, I think this would be ready for a discussion ... it takes the first step toward making scalaJS This PR modifies only Mdocs CLI. As far as I can tell, this PR works in the sense that it emits ESModules, and those modules work with docs own static server in
I think that would enable mdoc to provide documentation for a broad array of scala JS projects. |
There was a problem hiding this comment.
Just one minor comment from, otherwise looks good. I don't have a lot of background in JS, but I don't see anything problematic in merging this if it's useful for you.
But, out of curiosity, why is it beneficial over using normal scripts, especially in case of mdoc?
| .println(s"""<script type="module" src="$relmdoc"></script>""") | ||
| .toString | ||
| case NoModule => | ||
| new CodeBuilder() |
There was a problem hiding this comment.
Could we deduplicate this with the first case since it's the same?
There was a problem hiding this comment.
Yes. I wasn't sure if it was more readable to split the cases into the three cases, or whether it would be better to have an if... I can change it to deduplicate
There was a problem hiding this comment.
We could even just do case CommonJSModule | NoModule => which would be simplest
Well, the use case isn't 100% proven, but basically; EsModules allow importing other EsModules. To take an example - the excellent laminar shoelace library, its documentation is (as far s I can tell) a full-blown-full-stack sbt+vite+fly.io app. As things stand, I think it has to be that, because you gotta resolve the npm shoelace dependancy then build and bundle. The barrier to entry there, is actually pretty high - full stack scala plus a bundler (vite => entire nom ecosystem) plus setup cloud infrastructure.
Party trick - in browser referencing a CDN. In isolation, I agree this PR is not that useful :-) ... My hope, if you were comfortable with the direction of travel, is that I would then follow up this PR with something like this; for mdoc. The hypothesis is then, that something like laminar-shoelace or my own (lower profile :-) ) experiments, can be easily documented (via markdown - mdoc) and published in a static site (e.g. on GitHub pages - the browser just needs to hit up the CDN) - and they can depend on an arbitrary EsModule dependancy - without needing the bundler. The remaining problems, are already quite well solved... ... and without a bundler or backend! Said differently, I believe this could (no guarantees) ultimately crush the barrier to entry of documenting scala-js libs. |
|
That sounds awesome! It would be cool if you could later add a bit of documentation to mdoc if it pans out. |
First step to closing #638 .
A publish local off this branch actually seems to work.