Is an addons written in typescript (and webpack…) accepted by the reviewers of the source code before publishing?
Maybe @Lusito could share some of his experiences with TypeScript add-on development.
He mentioned one of his add-ons in this topic:
I’m planning to port some of my add-ons to TypeScript, @Lusito could you please share some thoughts about your experience? Maybe some pitfalls to avoid.
Also how did you started your project? Did you configured everything yourself or have you used some generator, like this one: https://github.com/phryneas/generator-webext-typescript
Sure I can.
I have 2 web-extensions that are written in TypeScript and compiled with WebPack:
If your code is minified, you will need to supply a zip file with all files necessary to regenerate the EXACT content of the minified version.
If the minified version that your supplied source generates does not match the one you submitted, your add-on might be deactivated!
I had this issue when webpack changed its minification process. Back then, I had webpack installed globally and since my webpack was different from the reviewers, my minified code didn’t match and my extension got disabled.
It’s a really bad feeling when this happens, so I can only recommend that you install your webpack inside your project and use that version to compile the code. Also make sure you supply a package-lock.json to avoid differences in versions.
Split your UI into components.
If you plan on creating more than a simple UI, make sure you split it early on into components. When I started my second extension Forget Me Not, I used the same method that worked good-ish for my last extension: Create an HTML file and use classes and ids to connect them to TypeScript. This became unmanageable at some point, so I had to rewrite the entire thing. And since my free time was limited, this took me several month and delayed other feature requests.
I know some people who like to use react. I myself noticed too much of a performance hit using react on smartphones, but I still wanted to split the UI into components in a react-ish kind of way. So I wrote tsx-dom to easily generate dom elements from TypeScript without having to use a heavy-weight lib like React. Under the hood it just calls document.createElement for you.
In the end, the rewrite was worth it, since it is now a lot easier to add new things and reuse existing code.
Aside from that, developing web-extensions with webextension-polyfill-ts is a breeze.
Others seem to enjoy it too, looking at the number of stars webextension-polyfill-ts has. Considering this is a niche library, 260 downloads a week on npm is also a good indicator I think.
If I didn’t make it clear enough: I love TypeScript and writing web-extensions is fun with it.
While I’m here promoting my Web-Extension related TypeScript projects, why not have a look at the web-extension translator as well.
I started dict.cc translation back when everything was old firefox add-on sdk and at some point I had to port it to web-extensions. I did this all myself without a generator and I would recommend you to do that as well.
These kind of generators don’t age well… often they stop working at some point or they keep using an outdated technique. But mostly you should do it on your own so you can learn all important parts of web-extension development.
I was able to setup a new typescript extension project following the example of another github project https://github.com/nyergler/typescript-react-redux-webext
From a technical point of view my problems are therefore at least partially solved.
My question was rather hinted at the Mozilla policy regarding publishing extensions in their store. Do they allow typescript extensions or do they have limitations on the technologies used?
As said, you need to supply your original code to mozilla when handing it in for review. Language of your choice should not be an issue. At least TypeScript has never been an issue for my extensions.