I’m maintaining a personal, unlisted (self-distribution) Firefox port of the
Trust Wallet browser extension for Chrome.
Automated validation fails with FILE_TOO_LARGE on three files:
background.js — 42.5 MB
chunks/walletkit.service-DTI1_gvs.js — 36.5 MB
chunks/SwapFeeRow-C6jj-4Ib.js — 6.9 MB
These are single minified bundle artifacts from the upstream build. The
upstream source is closed, so the bundles cannot be re-split or rebundled
from source. Only ~0.2 MB of the payload is extractable data; the rest is
code, so moving data to JSON files is not an option either.
Everything else in the package validates clean: 0 errors, 40 warnings
(eval/Function-constructor warnings from the minifier, plus
action.onUserSettingsChanged compat warnings).
Could you raise the per-file parse limit for this add-on
(id: trustwallet-port@abran.dev) so it can be signed unlisted? Happy to
provide the XPI or any additional info.
Hi, and thanks for the detailed write-up; it makes it easy to see exactly what you are hitting.
I am sorry, but this isn’t something we can grant. The limit is not a per add-on setting on our side, it lives in addons-linter as a fixed constant (MAX_FILE_SIZE_TO_PARSE_MB, currently 5 MB) and it applies to every submission the same way. There is no switch to raise it for a single add-on.
The reason is that a file we cannot parse is a file we cannot check. Signing, even for unlisted self-distribution, still depends on those automated checks running over the code. At 42.5 MB and 36.5 MB, these bundles are well beyond what the parser is meant to handle.
Realistically, the only path that would work is splitting the bundles into smaller files, which you have said is not possible with a closed upstream build.
For a personal install, temporary loading through about:debugging works, and Developer Edition or Nightly can run unsigned extensions.
One other thing worth flagging: publishing a port of someone else’s extension requires their permission, so please make sure you have the rights to redistribute that code before going further.