main.crx much smaller than the original zip file

[Artem Harutyunyan]

Hello,

I am not able to install the extension (id: ihhkmalpkhkoedlmcnilbbhhbhnicjga) from the Web Store after uploading it to the Web Store and passing the verification. The installation fails with:

Package is invalid. Details: 'Could not load options page 'settings.html'.'.

I double-checked that the .zip bundle that was uploaded and it did contain the file in question (settings.html). However, I have noticed that the `main.crx` file listed on the Developer Dashboard is much smaller than the original .zip file. I have downloaded and inspected it with Chrome extension source viewer and it seems like it actually is missing a bunch of files. In fact, the `main.crx` only contains some of the images, `mainfest.json` and  `a/verified_contents.json`. Everything else is missing. I have re-uploaded the bundle (with some code-changes and a version bump) thinking that maybe the file got corrupted while uploading but that didn't help. Now I see two versions of the extension (one verified, on still pending review) with incomplete `main.crx` on the dashboard. 

I have asked some friends to test the .zip file on their computers (by unpacking it and loading in developer mode) and I have tried it myself and didn't run into any issues. 

Did anyone run into this before? I would appreciate any pointers on how to debug this further. When I pack the extension locally through the browser the resulting .crx file is much larger (than the `main.crx` I see in the Developer Dashboard) and it does contain all the files as expected. Is the toolchain that Google uses to transform .zip to .crx available somewhere? I'd like to try to run it locally to see if I can replicate the issue. 

Many thanks in advance for any help on this! 

Cheers,

Artem.

[Artem Harutyunyan]

Hey Folks,

Turns out the problem was in the way we generate the .zip bundle. We were using adm-zip package for generating the zip file and were prepending file names inside the archive with `./` (noticed that when doing `zipinfo` on the archive). Since I didn't find a way to make adm-zip drop the './' in front of the file name I had to switch to another library (archiver). Once I got rid of the leading `./` the problem was gone (or at least the main.crx that I download from the developer console looks as expected). 

While we were figuring this out the extension got rejected (because it doesn't provide advertised functionality), and understandably so (it's actually unusable in its current form). I hope that the fix will take care of that issue.

Cheers,

Artem.