Yes, I was excited to find it there! The pjs dev tools are unknown territory to me, but I’m happy to support in any way I can. As far as I can tell the approach in Jaco’s PR looks solid though.
Hi Tarik,
I am part of the KILT Protocol team and would like to thank you for taking over the Polkadot-js. The team also wants to show their thanks too.
The KILT Team has found a bug in the Polkadot JS apps and has submitted a PR to fix it.
This is my first PR for the polkadot js apps. I don’t know what was the requirements.
Here is the PR in question: fix: updating the democracy proposal modal by Dudleyneedham · Pull Request #10296 · polkadot-js/apps · GitHub
It fixes a UI interface problem with voting on the democracy proposal modal. It doesn’t allow you to enter a preimage length, and if the preimage hasn’t been added through the preimages, it doesn’t calculate it.
The bug submits it with preimage length 0, which when enacted fails. I used some pre-existing code to fix it from the referendum code.
Kind Regards,
Dudley from the KILT Team
2 Likes
Glad to hear the repo is continued to be supported! 
Qu: Will there be an attempt to ameliorate the tech debt?
My attempts to raise PRs to the repo has been greatly hampered by the incredibly complex and hardcoded in-house package bundling solution (to name one of the frictions). For example the reams of regex and manual file copying, that goes into creating the packages; this - makes it quite challenging to pursue a decentralised development model when devs have to spend a few hours trying to trace through how the modules are assembled.
Qu : Will there be an attempt to ameliorate the tech debt?
Great Question, the short answer is yes, but with caveats. It depends on what we define here as tech debt, what the scope of it is, and how much work may need to be done vs the actual positive impact it will have.
My biggest goal to help contributors and those who may have difficulties working around a lot of the libraries is writing development documentation and guides which should alleviate the friction felt when figuring things out. There are a lot of scripts and nuances that once known really make for easier development.
2 Likes
It’s quite challenging to publish a library that works on all the common JavaScript runtimes. Some thoughts 
Would be very nice to decide what is supported and what not:
- browsers (which ones and which versions)
- node (cjs?, esm)
- deno (versions)
- bun (particularly compatible with their websockets, depends on version…)
- not exactly a runtime but the type definitions and typescript sources as well
- other runtimes (maybe some edge ones w/ particular nuances)?
Afaik, a ready to go bundler that solves all of this does not exist… Do you know about any magic isomorphic bundler with oob support for almost “everything”?
Dual publishing CJS/ESM is tricky but possible - many repos do it now without having to resort to manual scripts.
I’ve been using tsup to great effect. Using workspaces offered by yarn or pnpm will also help code separation allowing for more client support
I see your point in which runtimes to support - but tablestakes for backend is: node.js.
Bun/deno/cloudflare runtimes are all nice to haves given polkadot tech isn’t exactly ubiquitous 
Great initiative by Tarik!
Related to this, we – Parity – would like to find out more about how developers and power users use Polkadot.js Apps in their work. As part of that we are conducting a small series of user interviews (20 to 30 minutes long), to ultimately improve the usability and experience of our tools and tech more broadly.
If you’d like to participate, please feel free to book a slot via this Calendly link.
Or message me here or on Element (@michel:parity.io)
3 Likes