# Motoko Dependecy Hell **URL:** \ **Category:** Motoko\ **Created:** [September 6, 2025, 7:20pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932 "2025-09-06T19:20:15Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Gekctek](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gekctek/32/6863_2.png) [@Gekctek](https://forum.dfinity.org/u/Gekctek)\ **Post date:** [September 6, 2025, 7:20pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/1 "2025-09-06T19:20:15Z")
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](https://docs.mops.one/dependency-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 Anyways I was wondering if there are any plans to address this at a tooling level, MOPS can only do so much. @rvanasa i see that there was this [experiment: `--override` flag to support multiple package versions by rvanasa · Pull Request #5124 · dfinity/motoko · GitHub](https://github.com/dfinity/motoko/pull/5124) but im not sure if its being worked on anymore since base library changed to core which fixes that issue 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 ---
**Author:** ![DATHKA](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DATHKA](https://forum.dfinity.org/u/DATHKA)\ **Post date:** [September 7, 2025, 3:03pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/2 "2025-09-07T15:03:02Z")
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. ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [September 8, 2025, 2:11pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/3 "2025-09-08T14:11:44Z")
> [@Gekctek](#): > > @rvanasa i see that there was this [experiment: `--override` flag to support multiple package versions by rvanasa · Pull Request #5124 · dfinity/motoko · GitHub](https://github.com/dfinity/motoko/pull/5124) but im not sure if its being worked on anymore since base library changed to core which fixes that issue 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 ---
**Author:** ![Gekctek](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gekctek/32/6863_2.png) [@Gekctek](https://forum.dfinity.org/u/Gekctek)\ **Post date:** [September 8, 2025, 10:03pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/4 "2025-09-08T22:03:53Z")
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 ---
**Author:** ![Gekctek](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gekctek/32/6863_2.png) [@Gekctek](https://forum.dfinity.org/u/Gekctek)\ **Post date:** [September 8, 2025, 11:49pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/5 "2025-09-08T23:49:01Z")
Also @rvanasa, question: if i have a `mops sources` of ```auto --package core@1 .mops/core@1.0.0/src --package core .mops/core@1.0.0/src ``` Will this include the source module twice and make the resulting WASM larger than if it was just ```auto --package core .mops/core@1.0.0/src ``` ---
**Author:** ![ZenVoich](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/zenvoich/32/5969_2.png) [@ZenVoich](https://forum.dfinity.org/u/ZenVoich)\ **Post date:** [September 9, 2025, 5:09am UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/6 "2025-09-09T05:09:26Z")
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. ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [September 9, 2025, 5:34pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/7 "2025-09-09T17:34:43Z")
> [@Gekctek](#): > > Will this include the source module twice and make the resulting WASM larger than if it was just … 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. ---
**Author:** ![Gekctek](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gekctek/32/6863_2.png) [@Gekctek](https://forum.dfinity.org/u/Gekctek)\ **Post date:** [September 9, 2025, 7:13pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/8 "2025-09-09T19:13:56Z")
> [@Gekctek](#): > > 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. @rvanasa any thoughts on this? 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 ---
**Author:** ![rvanasa](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/rvanasa/32/23650_2.png) [@rvanasa](https://forum.dfinity.org/u/rvanasa)\ **Post date:** [September 9, 2025, 9:57pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/9 "2025-09-09T21:57:05Z")
I’m not aware of a simple way to do this but will mention this thread internally just in case. ---
**Author:** ![Gekctek](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gekctek/32/6863_2.png) [@Gekctek](https://forum.dfinity.org/u/Gekctek)\ **Post date:** [October 8, 2025, 9:13pm UTC](https://forum.dfinity.org/t/motoko-dependecy-hell/56932/10 "2025-10-08T21:13:31Z")
> [@Motoko WASM size diagnosing - Part 2](https://forum.dfinity.org/t/motoko-wasm-size-diagnosing-part-2/58694): > > Im looking for some help/tips for figuring out what takes up so much space in my Motoko WASM output. The main issue is that I am going over the 2MB cap and I have many MOPS packages referenced and can’t seem to figure out the specific dependencies/code that are the issue or can be slimmed down. Manual inspection has been no luck and inspecting the WASM hasn’t been fruitful, except for one thing that I will mention below I can cut my WASM size from 2.6 MB to 1.8 MB with ‘trimming’ the WASM of …