Adding SVGs to the ui-lib

[dahaca]

I have a similarly structured monorepo and would like to know what the clearest way of including svgs to the ui-lib is. Would appreciate any amount if info thanks :)

[belgattitude]

Hey @dahaca it depends if you want to publish ui-lib outside of the monorepo...

If you don't have to straight away I would simply

.
├── apps
│   └── web-app                 
│       └── tsconfig.json     (here we have to ensure correct paths)
├── packages
    └── ui-lib      
        └── src
            └── icons
               ├── index.ts (optional barrel to regroup all icons)
               └── play.svg (and all others...)

Then ensure the consuming has the path aliases defined in its tsconfig

{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      // Hey Notice the '*', it will allow to impor from ui-lib subdirectories
      "@your-org/ui-lib/*": [
        "../../../packages/ui-libsrc/*",
      ],
      "@your-org/ui-lib": [
        "../../../packages/ui-lib/src/index",
      ],
    },
  },
}
 

Then to keep easy I would rely on svgr/webpack (or next-image) in the app next.config.js

  webpack: (config, { defaultLoaders, isServer }) => {
    config.module.rules.push({
      test: /\.svg$/,
      issuer: /\.(js|ts)x?$/,
      use: ['@svgr/webpack'],
    });
    return config;
  },

That should allow you to simply import the svg

import playIcon from '@your-org/ui-lib/icons/play.svg;

export const Header = () => (<img src={playIcon} />); // or something else

You can of course add a barrel...

but I'm not sure if we don't need to do something more in that case.

Released an example with #278

PS: If you need to publish and use outside, it's a little more complex

[belgattitude]

Oh you removed the question 😄

Can you revert, it's a nice one

[belgattitude]

had to add a type file to ui for importing svgs without TS errors

Yes that's a hard one, I went with creating this one: https://github.com/belgattitude/nextjs-monorepo-example/blob/main/apps/web-app/src/types.d/react-svgr.d.ts. Which gives a little more than just plain svg.

What I have to figure out now is how to deploy :D Likely the public directory plays no role here since the svgs are embedded into chunks.

Exactly... They'll be be part of webpack / nextjs build (following it's own optimization). That said, you can customize the loading if needed https://react-svgr.com/docs/webpack/#using-with-url-loader-or-file-loader. (and add size limits... but it's quite advanced imo)

If you have larger svg's: like illustrations that you don't want to be part of the build and use with <img src=...> there's also the shared asset folder strategy https://github.com/belgattitude/nextjs-monorepo-example/tree/main/static/assets/images/undraw. That's the proposed strategy for shared images.

What I have to figure out now is how to deploy :D

Do you have a specific target ? (vercel, netlify, aws, docker...)

[dahaca]

Docker. Haven't reached deployment yet but since the svgs become part of the build there will be no difference between all that and a classic Next project. .next, public, configs are all you need to start after building a project. I am not building common separately btw, decided to keep it simple and using the monorepo architecture mostly for avoiding duplication, so it's even simpler. The only inconvenience that's left is that I can't use absolute imports (TS paths) in both web and common, so I have to use relative paths, which is ugly especially when importing from common. Any ideas on how to fix that?

[belgattitude]

The only inconvenience that's left is that I can't use absolute imports (TS paths) in both web and common, so I have to use relative paths, which is ugly especially when importing from common. Any ideas on how to fix that?

I don't get it totally :)

If you're working in a strict way (packages and apps have all a package.json) and kept strict with path aliases there won't be problem afaik...

Ie in your app:

import { whatever is exported in the barrel index.ts } from 'common';
// I suggest to give an org to your package common, cause how to differentiate
// package that might exist on npm ?
// import { whatever is exported in the barrel } from '@dahaca/common';

//Or

import { whatever is exported in the barrel typeguard/index.ts } from '@dahaca/common/typeguard';

The question of exporting everything from the common package... ie: import {a,b,c,d,e,f,g,h} from 'pkg' is generally solved by splitting your common package into smaller ones (at some point you'll have a lot). Not the only option, but personal recommendation.

Check in the howtos in

For tsconfig: https://github.com/belgattitude/nextjs-monorepo-example#step-32-in-tsconfigjson
For package.json: https://github.com/belgattitude/nextjs-monorepo-example#step-31-packagejson

Docker.

Be cautious it's totally doable, but I would always consider serverless, vercel or netlify. Docker and nextjs does not play well together

But If you're locked into docker, open a discussion I might commit things that helps.

[dahaca]

Thank you for your help! You've done exceptional work 🤓 And yes, unfortunately, I am locked to docker. Why are you advocating for serverless though? what are the advantages over docker? Docker is not only about deploying but developing in containers.

[belgattitude]

Developing in a container is okay, having performant delivery another one.

Take a look in the docker / docker-compose you'll find in this repo... they're not up to date, but they'll help for the basics startup in a monorepo... Next things you'll face

• environment variables and how not to rebuild all the time (it's okay at first)
• size of the image (all prod deps)

I have a lot to say, but I suggest to take some time on it and eventually open a new discussion.

Will be a pleasure to discuss and improve... Interesting subject 😄