Ckeditor5: Rebuilding the bundle gives non-deterministic results due to language files

[wwalc]

There is a chance that when creating language files the order of entries is different on different computers. Ideally, the entries should be sorted by something which will be consistent (e.g. by source package name, alphabetically), to not rely on system defaults (e.g. file modification time).

I'm suspecting that the order is random because I just cloned the classic build, run npm run build and got all the language files modified.

Such behaviour is causing confusion and leads to thinking that perhaps my setup is wrong.

[ma2ciek]

It's a little bit tough subject.

Webpack loaders load files simultaneously, so the order of translations depends on the order of resolved files.

We'd need to resolve all imports and find all t() calls before webpack build task starts to be able to provide deterministic results.

[ma2ciek]

Recently we've had an error with cached translations - https://github.com/ckeditor/ckeditor5-dev/issues/458. I don't know if that problem could happen to someone, but I can imagine that someone can refresh the page and the editor will reload to the new version while translations will stay in the previous version. On the other hand, almost nobody encounters this problem yet. So 🤷‍♂️

[ma2ciek]

An idea came to my mind some time ago. While building for the first time, we can store translation mapping in a file, e.g. build/translations/mapping.json, so in the next build, we could reuse this mapping to preserve the same order and to make the build deterministic. It won't make the build 100% deterministic, but it will make rebuilding 100% deterministic.

I'd enable this by default but I'd also add an option to don't create/use this mapping file.

WDYT?

[Reinmar]

Sounds good to me. But we need to:

1. commit this file so if someone rebuilds an existing build (cloned repo) they get the same results,
2. figure out when this mapping.json should be ignored (invalidated cache) because if src/ or lang/ of any package has changed, we need to create new mappings.

Also, if we talk about making building more deterministic, maybe we should have lockfiles in build repos, ensuring that the same version of deps are used?

There would be two problems, though:

1. can we easily have lockfiles for yarn and npm together?
2. also, won't this cause problems for people who want to update their builds? You cloned a build repo, add some deps or something and suddenly you need to think about lockfiles (which are yet additional thing to learn). The same when merging from an upstream – conflicts and confusion.

[Reinmar]

Also, if we talk about making building more deterministic, maybe we should have lockfiles in build repos, ensuring that the same version of deps are used?

Another thing that we could do to make builds more "stable" is saving strict version numbers (x.y.z) instead of caret ranges (x.y.z) in their package.jsons. That won't ensure as much stability as a lockfile, but would be a good step forward. WDYT?

[ma2ciek]

1. commit this file so if someone rebuilds an existing build (cloned repo) they get the same results,

yes, among the built translation files.

1. figure out when this mapping.json should be ignored (invalidated cache) because if src/ or lang/ of any package has changed, we need to create new mappings.

During the translation process, if we find that the translation key doesn't exist in the existing mapping, we can be sure that something has changed and recreate mapping based on the translation keys already found and next ones. A very similar thing to yarn's lock file.

can we easily have lockfiles for yarn and npm together?
also, won't this cause problems for people who want to update their builds? You cloned a build repo, add some deps or something and suddenly you need to think about lockfiles (which are yet additional thing to learn). The same when merging from an upstream – conflicts and confusion.

yarn or npm will ignore nested package-lock.json, yarn.lock. We'd have to somehow remove node_modules and run npm install before the release from the ckeditor5-build repositories. But I don't know the community awareness in this topic.

[Reinmar]

yarn or npm will ignore nested package-lock.json, yarn.lock

That's the point – this will only make a difference if you use the build repo directly – just like everyone outside are doing :D