wasm release to npm

[johanneswilm]

Hey,
congratulations on including official wasm support in the 3.9 release!

In order to make the package really useful for web developers, it would be good to also have the package available on npm with some wrapper scripts to make it easier to use.

For my own project, I forked, modified and published the package wasm-pandoc last year and I have now updated it to work with the official 3.9 wasm binary. You can find it here: https://www.npmjs.com/package/wasm-pandoc

I would think it would make more sense that someone closer to the pandoc community would maintain such a package.

Again, congrats on the release!

[jgm]

I've got enough of a maintenance burden that I'm happy to have someone else maintain (especially when they know more than I do about JavaScript).

However, I do wonder why the GPL license isn't required. How is this different from a case where a GPL-licensed library is dynamically linked with an application that uses it?

[johanneswilm]

Hey @jgm ,
so first of all I believe I believe the repo has the MIT license because that is what the license was of the original repository that I forked https://github.com/haskell-wasm/pandoc-wasm/blob/master/LICENSE

I am also not opposed to GPL-type licenses - I usually pick LGPL for libraries so that people can include it on their commercial websites. Fidus writer is AGPL.

I see other pandoc wrappers are licensed under MIT (for example for PHP ). I am not a software license lawyer, but it looks to me like you might be right and the wrapper needs to fall under the GPL as well. I am not so sure what that means for other JavaScript software calling the functions exposed by the wrapper.

I can continue to maintain this for now, but I am also very open to someone else from this community taking over as I am mainly a JavaScript developer and not all that familiar with haskell, etc. .

[tarleb]

I also don't know enough about the JS ecosystem to maintain this.

Pinging @georgestagg, who is the maintainer of the pandoc-wasm package. It would be awesome if you two could team up to maintain an "officially sanctioned version".

[johanneswilm]

@tarleb Yes, unfortunately @georgestagg stopped working on it 2 years ago [1] and he points to the repository [2] that I forked from. I forked because it also [2] was no longer maintained. Here is my PR [3] where I tried to get everything merged into [2].

[1] https://github.com/georgestagg/pandoc-wasm?tab=readme-ov-file

[2] https://github.com/haskell-wasm/pandoc-wasm

[3] haskell-wasm/pandoc-wasm#10

[johanneswilm]

Here @georgestagg said about a year ago that he didn't want to transfer his archived package to me as he was waiting for @TerrorJack to continue work on the package [1]. Unfortunately @TerrorJack had stopped working on this back then and has not taken it up since. I ended up distributing my maintained version of the package under the name wasm-pandoc instead.

Maybe now with all this time having gone by, @georgestagg is willing to take another look at it and we have just one pandoc wasm package in npm?

[1] haskell-wasm/pandoc-wasm#10 (comment)

[georgestagg]

Maybe it would be better to rework the existing code in the wasm directory in this repo, separating out the UI code and building a JS (or preferably TS) library to be used for an npm package, rather than trying to pull in the MIT code from the existing haskell-wasm fork. I believe that would avoid the licensing issue.

I’d be willing to help out and work on this, but won’t be able to dedicate a good amount of time to it for a couple weeks at least.

Whatever the decision I am willing to update the pandoc-wasm npm package I maintain to an officially blessed Pandoc wasm binary, remaining as maintainer of the npm package if necessary.

[johanneswilm]

Maybe it would be better to rework the existing code in the wasm directory in this repo, separating out the UI code and building a JS (or preferably TS) library to be used for an npm package, rather than trying to pull in the MIT code from the existing haskell-wasm fork. I believe that would avoid the licensing issue.

MIT can be relicensed as GPL, so that shouldn't be a problem. It's a package that now has been used in production for quite a while, so I don't personally see why one would start from scratch again.

I’d be willing to help out and work with this, but won’t be able to dedicate a good amount of time to it for a couple weeks at least.

I have now already spent a lot of time on it over the past year. So I'prefer not to spend more time on creating something entirely different. But if someone else is willing to do so, I'd be happy to switch from the package that I created to that other package.

[johanneswilm]

Whatever the decision I am willing to update the pandoc-wasm npm package I maintain to an officially blessed Pandoc wasm binary, remaining as maintainer of the npm package if necessary.

Ok, so you are still maintaining it @georgestagg ? The repository gives the impression that you stopped doing so 2 years ago. If you are still maintaining it, then could you unarchive your repository and I can make this all a PR into your repository.

[georgestagg]

Ok, so you are still maintaining it @georgestagg ?
The repository gives the impression that you stopped doing so 2 years ago.

I mean “maintainer” as in “current owner of the package named pandoc-wasm on npm”.

MIT can be relicensed as GPL, so that shouldn't be a problem.

Does that not require the agreement from all the relevant code authors?

---

My position is the same as it was last time we spoke. I am happy to transfer the ownership of the npm package to you if the original author of the code that you are publishing to npm (@TerrorJack or @tweag) agrees to it. As of yet I have not seen either account agree to it or accept your PR to the original repo. The last commit to that unforked repo was 4 months ago, it has not been abandoned.

I am also happy to transfer ownership of the npm package to @jgm, if he has an npm account, for him to decide what to do with.

I’m also happy to help work on preparing a new npm package, based on the existing GPL code in the wasm directory of the pandoc repo, in the near future, and maintaining that new package on npm.

I hope we can all come to an agreement.

[johanneswilm]

MIT can be relicensed as GPL, so that shouldn't be a problem.

Does that not require the agreement from all the relevant code authors?

No. You can take some code that is MIT-licensed and incorporate it into your GPL-app and continue using it under the terms of the GPL license [1].

My position is the same as it was last time we spoke. I am happy to transfer the ownership of the npm package to you if the original author of the code that you are publishing to npm (@TerrorJack or https://github.com/tweag) agrees to it. As of yet I have not seen either account agree to it or accept your PR to the original repo.

But we have been waiting for a year now. I think you should take a look at the contents of the repository. There is very little from that initial code left. There have been two main versions:

0.8 : This was the original code but with a lot of work put into making it a viable package that can be used by other software with helper functions and thoroughly tested.

1.0: Here the entire logic for building the wasm package has been removed (this was what @TerrorJack had built). Instead, it takes the official 3.9 pandoc wasm binary, which it downloads directly from the pandoc repo, and then adds the wrapper scripts I built for version 0.8 - with some additions/modernizations.

The last commit to that unforked repo was 4 months ago, it has not been abandoned.

If you look at what that commit does, it updates a link to their matrix room. The last commit that did something about the code was November 26, 2024. In total there have been 11 commits in the initial repository, while there have been 87 commits in my repository since the fork.

[1]

Is the MIT License compatible with GPL?
Yes, the MIT License is compatible with GPL. You can combine MIT-licensed code with GPL-licensed code, but the resulting work must be licensed under GPL due to GPL's copyleft requirements.

https://fossa.com/blog/open-source-licenses-101-mit-license/

[georgestagg]

But we have been waiting for a year now. I think you should take a look at the contents of the repository. There is very little from that initial code left.

Very little is not the same as none. It is the principle of it — your project remains an unofficial fork.

I can see that John and Tweag I/O have been working together on Pandoc for Wasm, as it currently exists in this repository, in at least 2025. And so my stance is as before: I will transfer ownership of the pandoc-wasm npm package to themselves or any official maintainer of their choosing, maintaining ownership otherwise.

pandoc/wasm/pandoc.js

Line 2 in 061055d

Copyright (c) 2025 Tweag I/O Limited and John MacFarlane. MIT License.

Of course, that person might be you, and if it is so I would recommend doing so by upstreaming your existing packaging work and utility functions as a PR to this repo, rather than maintaining a fork of an older repository.

[johanneswilm]

Very little is not the same as none. It is the principle of it — your project remains an unofficial fork.

I have a suspicion that we have different ways of understanding of how open source software works. What is an "unofficial" fork?

I contributed code to some part of KDE maybe 20 years ago. Should I now forever be angry at Apple and Google for having made forks of Konqueror (Google Chrome and Safari) and potentially included some of my code? The license allowed that.

My fork was not at all mean to be an attack on anyone or taking credit for the work of others in any kind of way. In fact I made sure to attribute Terrorjack and anyone else I believed had contributed. It's just that you stopped working on your project two years ago and @TerrorJack has not shown any interest in maintaining a JavaScript package with releases on JavaScript distribution systems and has stopped working on that package 15 months ago.

And I'm not even interested in maintaining a package. I just need someone to provide a package on npm. So for the time being I have been that person. But I also have way too many other packages that I am maintaining and I'd really prefer if you would unarchive your repository and take over this job - if you have the time for it.

I have a hard time seeing how anyone benefits with the current setup where you sit on the registered name in npm, but you don't make any use of it because you archived your project. And the package that I have spent a lot of time working on (the JavaScript part, to be sure) has to take a different name that people will have a harder time finding it under in npm. It just seems like a waste of a lot of resources.

[johanneswilm]

Of course, that person might be you,

Or that person may be you. Honestly, I have more than enough other things to do and I'm not a haskell person at all. Or a wasm person for that matter. I just need a package that does more or less what the package that I have published already can do today.

The thing is just that I already put all that together and it's working for me, so if you want to do it totally differently, I think it would be fair if you would be the one to do the refactoring.

and if it is so I would recommend doing so by upstreaming your existing packaging work and utility functions as a PR to this repo, rather than maintaining a fork of an older repository.

OK, I'm up for doing almost anything. But I'm not sure I fully understand what you are suggesting. Are you suggesting that we add the JavaScript wrapper code to the main pandoc repository? If @jgm wants to do it that way and you guys can think of a way to organize the code properly, it would sound like an OK solution for me. Just let me know if you want me to do any code movement or if you guys want to do it yourselves.

The wrapper code contributions of me fall under MIT, so that means anyone is free to rerelease it as GPL. And as @jgm points out, it may be that that entire repository falls under GPL anyway.

[georgestagg]

I have a suspicion that we have different ways of understanding of how open source software works.

This argument is silly and not productive, let us agree to disagree.

And I'm not even interested in maintaining a package. I just need someone to provide a package on npm. So for the time being I have been that person. But I also have way too many other packages that I am maintaining and I'd really prefer if you would unarchive your repository and take over this job - if you have the time for it.
[...]
The thing is just that I already put all that together and it's working for me, so if you want to do it totally differently, I think it would be fair if you would be the one to do the refactoring.

OK, I can do that refactoring work. To make myself clear,

• I am willing to be the named maintainer of an official pandoc wasm package on npm.
• I am willing to do the initial refactoring work to build and maintain this package.
• I am not willing to simply republish @johanneswilm's fork verbatim as it exists today, but I am willing to re-use existing utility functions if it makes sense.
• I would prefer not to unarchive and replace my old pandoc-wasm project on GitHub, the archived code lives there and should remain there.
• I will likely not be able to do the work for a couple of weeks, because I have other WIP right now.

It is not that I want to "do it totally differently", it is just that if I am to do this then I would like the npm package to be upstreamed and live in the wasm directory of the official pandoc repo, rather than in any one third-party person's GitHub repo. And I would want it to be initially based on the latest existing JavaScript code from John and Tweag I/O that already exists there, rather than the older @TerrorJack version.

Are you suggesting that we add the JavaScript wrapper code to the main pandoc repository?

Yes, there already exists JavaScript code here to load the Wasm binary for the Pandoc web demo, it just needs reworking into a library.

If all the above is acceptable to everyone involved, then I will maintain the package. I could create a PR to this repo reworking the existing JS code into an npm package, and once that is merged deal with the a required GHA workflow to publish the package to npm whenever a new release of Pandoc is made. This can all be updated and maintained by reviewed PRs to this repo, I would be happy to be tagged in any Issues and PRs specifically related to the npm package for review.