builld is too big

[m4rcTr3y]

when project is built in nuxt, the mdijs bundle is big its about 1.+MBs .. how do i reduce it

[therufa]

hi @m4rcTr3y,

to me it seems that you import all the icons, but sadly the bundler can't shake off unused ones. In order to reduce the build, you could include only the specific icons you use in your build. A bit less convenient, but to my knowledge, it's the only way to deal with this issue in this setup.

so instead of going with:

import * as mdijs from '@mdi/js'

// .....

createApp(App).use(mdiVue, {
  icons: mdijs
})

you could try this:

import {
   mdiPlayStation,
   mdiAccount,
   mdiAccessPoint
   // etc ...
} from '@mdi/js'

// .....

createApp(App).use(mdiVue, {
  icons: {
	mdiPlayStation,
	mdiAccount,
	mdiAccessPoint,
	// and so on
  }
})

I hope this solves your issues regarding build size, convenience-wise there's little I can do right now.

[loxK]

@therufa Hi. So what is the point of importing at createApp stage ? Isn't it better to import in each component where the icons are used to take advantage of features like code splitting ?

[therufa]

Hi @loxK, The main reason to moving everything to the init state was to reduce the build size of this package. Before we were close to 20Mb which I didn't feel comfortable with (even though this wouldn't translate to the end product) serving several thousand times a month. The explicit import serves the sake of code splitting, since the @mdi/js lib is basically just one large file with all the paths for all the icons of the mdi library.

I hope this clarifies some of your questions. As with everything I'm open for recommendations regarding improvement, every contribution is welcome ;)

[Zony-Zhao]

I still have a huge mdi bundle. Is there anything I'm missing?

[nadirabbas]

@Zony-Zhao When you build the project, it will be smaller.

[crhistianramirez]

@therufa I think your concern is valid but misplaced. Developers are going to opt for the path of least resistance which is to pull in the entire icon set and that is going to cause bigger bundle sizes on production builds. That should be more concerning than a large bundle size on a library that is going to be largely tree shaken away. It also runs counter to the strategy that @mdi/js takes which is to offer a route where by default code is tree shakeable.