Until now, I have been able to manage and get around issues with Motoko package dependency versions because I have been creating libraries without many dependencies and versions haven’t changed that much. Now that I have been working at a high level, like building HTTP framework libraries, the story is starting to change.
Essentially we have a problem right now that by default packages with the same name only get to use a single version of it, even if there are different major versions (breaking changes)
MOPS does have a way around this that helps with MOST issues with Dependecy Version Pinning but not all.
First its kinda a pain to pin everyone of the libraries, but also it only really works if ALL the libraries adopt that pattern. I can update mine but if I have an issue with someone else not pinning I have issues
For all the devs out there. I would recommend doing the dependency version pinning in MOPS.
I am currently trying out pinning to the major version like “core@1” vs “core@1.0.0” so the packages can always use the latest but not break
Yep, I’m going through some of this pain - I’m using a MOPS package that has a dependency on core@0.6.0 and there are breaking changes in core@1.0.0 that affect it (function name changes!). You’re right, version pinning can help but not if the package I’m dependent on doesn’t use it.
It is a concern that an update to one package I’m using from MOPS could throw my whole project out. So agreed, I’d really like to see this handled at the tooling level.
That is correct—we recognize the value of this and are internally discussing ways to support a dependency solver or similar solution. CC @kritzcreek@ZenVoich
Also now i have discovered that I am blowing up the size of my output wasm files because now I get 2 packages instead of one, like core@1 and core might or might not be the same version, but since i use core@1 and someone else uses core it uses 2 ‘packages’
I have been having a hell of a time trying to get my wasm now down in size, are there any good ways to see what specific modules the compiler is using, so i can evaluate the worst offenders and try to have the 3rd party library updated or something.
I am able to see all the mops sources but im assuming its doesn’t use certain modules if they are not referenced
Also any thoughts in general on how to deal with this in the short term? Besides forcing all the 3rd party libraries I use to update with using the package@majorVersion dependecy version pinning
Does the Motoko compiler use tree shaking for files and symbols?
So if I import only core/Int and use only Int.abs the build will not include other files from core package and other functions from Nat module.
The files would only be included once. Behind the scenes, the --package flag simply maps the mo:* import to a file system directory, so both packages would point to the same modules.
I think i can slim things down a bit by specifying package and package@version to be the same version so i override dependency dependencies (assuming no breaking changes), but I am still looking to see what is the biggest bloat
I am trying to get an ICP ninja template going but im breaking the max size and need to figure out the lowest hanging fruit