Bundle size too large due to dev users

[statictype]

~3.5MB of the minified and gzipped production bundle size comes from dev users public keys artifact, without actually importing any dev users in the project. Looks like a regression of #951

The reasoning behind this approach of creating 100k users for testing is not clear to me.

[tjjfvi]

The reasoning behind this approach of creating 100k users for testing is not clear to me.

All the test users we ultimately want to use need to be generated upfront as they are all put into the chain spec before launch. Since we cannot know how many test users we may need, we chose an arbitrarily high number, that should be enough for any usecase. However, it takes a while to generate all these users, especially in CI, so to improve performance, we generate this once and commit it.

This file is only ever needed on the server, though, so it should not be included in the client bundle. We'll tweak the dependency graph to make sure it's not included from the mod.ts.

[tjjfvi]

On another note, you might be happy to hear that the second-largest rectangle there (capi_crypto_wrappers.generated.js) will be gone as of #1060

[statictype]

i just wonder what was the issue you encountered which led you to conclude there is a need for many different users.
the default dev accounts seem to be sufficient for all testing needs i know of.
is restarting the dev chain not possible? or transferring smaller amounts to prevent running out of balance? set the initial balance of default dev accounts to max u128? sudo set balance before all tests?

[tjjfvi]

If two different tests running in parallel use the same test users, they will attempt to send two extrinsics with the same nonce, which will result in one of the two failing.

[statictype]

finding a way to increment the nonce sounds like a better way to go than generating 100k test users, imho
i am sure this is possible.

[harrysolovay]

@statictype I understand your concern, but I believe the system for vending untouched test users is preferable. It allows us to forgo thinking about potential conflicts between integration tests. Hopefully your concern will be mitigated by some changes that @kratico is soon to PR, which will ensure the large dev users artifact isn't accidentally exposed through Capi's root.