Ckeditor5: The "yarn clean" task should get rid of yarn.lock (package lock)

[oleq]

📝 Provide a description of the improvement

Since yarn.lock is no longer versioned, doing yarn clean is just half of the story as I found out today the hard way: got some random ESLint errors due to outdated packages installed by yarn boostrap that followed the clean-up.

I think yarn clean should get rid of package locks as well now.

---

If you'd like to see this improvement implemented, add a 👍 reaction to this post.

[Reinmar]

Could you explain what's the problem in having yarn.lock? By default yarn install ignores it anyway, AFAIR.

[oleq]

Not sure what happened in my case. It works now and I have no easy way of reproducing it.

Anyway, In a F2F conversation with @pomek I was informed that yarn install re-generates yarn.lock from scratch but somehow I didn't work for me and I had to get rid of it manually to obtain the latests versions of packages.

[mlewand]

Yea, only yarn install --frozen-lockfile should consider old yarn.lock. @oleq since we have no way to reproduce it I'll close it for now. However, if you face it once again please feel free to reopen it and add repro steps.

[Reinmar]

:tada: I stumbled upon the same issue.

We use now >= as a version specifier in ckeditor5-internal packages. And in export-pdf we have "ckeditor5-track-changes": ">=20.0.0". 

I did yarn clean && yarn install and got track-changes in version 22.0.0.

When I deleted yarn.lock and reinstalled packages again, yarn installed 23.0.0.

So, this means that yarn.lock is used in this case.

[mlewand]

We've received a report from customer about the module duplication error when using CKEditor5 with MathType plugin. I'm reaching out to see if it was also caused by deps being picked from yarn.lock.

[pomek]

The same issue can occur with package-lock.json I guess.

[pomek]

Workspaces from npm@7 work with our setup so the package-lock should be removed as well because other teams (not our) can use npm instead of yarn.