only-includes-used-icons broken with mono repos.

[garronej]

In mono repose the only-includes-used-icon script is broken because the node_modues directory where @codegouvfr/react-dsfr and other potential plugin are stored in an upper dir.

See: https://github.com/DISIC/monfranceconnect

[garronej]

8bc39d7

[stephane-ruhlmann]

I get the same problem using Docker and pnpm in my monorepo, thanks for the fix @garronej 🙏

[garronej]

Hi @stephane-ruhlmann,

Are you saying that tou used to get this error but this fixed it or that you're still getting the error?

[stephane-ruhlmann]

Hello @garronej

Sorry that wasn't clear.
I just tried again with v0.72.4 (including this) and still have the same error running predev or prebuild hooks need by the lib:

sh: only-include-used-icons: not found

You can find our code here, or I can come up with a minimal similar project to reproduce if needed : https://github.com/incubateur-ademe/benefriches/tree/chore/create-basic-layout-with-dsfr/web

[garronej]

Hello @stephane-ruhlmann,

I hope you're doing well. I would like to point out that the issue you're facing seems to be more closely related to the way your Docker image is being built.

Here is a potential solution, although I haven't been able to fully investigate its validity:

FROM node:18-alpine as base
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable
COPY . ./app
WORKDIR /app

FROM base as deps
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install


FROM base
COPY --from=deps /app/node_modules /app/node_modules
EXPOSE 3000 
+RUN node ./node_modules/.bin/only-include-used-icons
+CMD ["node", "./node_modules/.bin/vite"]
-CMD ["pnpm", "dev"]

That being said, you might want to reflect on the method you're using to construct your Docker image for your Single Page Application (SPA).

In an ideal world, your Docker build process would consist of two steps: initially you build the app, and then serve your static files using an NGINX image. This method would effectively reduce the size of your image and eliminate the need to serve your application using the Vite development server, which may not be the most optimal solution.

Here's an example of how you could structure your Dockerfile (please adjust it to suit the specifics of your pnpm and repository):

# build environment
FROM node:18-alpine as build
WORKDIR /app
COPY package.json yarn.lock tsconfig.json vite.config.ts ./
COPY public ./public
COPY src ./src
RUN yarn install --frozen-lockfile
RUN yarn build
COPY nginx.conf ./

# production environment
FROM nginx:stable-alpine
COPY --from=build /app/nginx.conf /etc/nginx/conf.d/default.conf    
WORKDIR /usr/share/nginx
COPY --from=build /app/build ./html
ENTRYPOINT sh -c "nginx -g 'daemon off;'"

ngnix.conf

server {
    listen 8080;

    gzip on; 
    gzip_vary on; 
    gzip_min_length 1024; 
    gzip_proxied expired no-cache no-store private auth; 
    gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/javascript application/xml; 
    gzip_disable "MSIE [1-6]\.";

    root /usr/share/nginx/html;
    index index.html;      

    try_files $uri $uri/ /index.html;

    # Any route containing a file extension (e.g. /devicesfile.js)
    location ~ ^.+\..+$ {
      try_files $uri =404;

      location ~* \.(?:html|json|txt)$ {
        expires -1;
      }

      # CRA generates filenames with hashes so we can
      # tell the browser to keep in cache the resources.
      location ~* \.(?:css|js|woff2?|eot|ttf|xml|md)$ {
        expires 1y;
        access_log off;
        add_header Cache-Control "public";

      }

    }

}

I hope this helps and steers you in the right direction. If you have any other questions or need further assistance, please don't hesitate to ask.

Best Regards.

[stephane-ruhlmann]

I really appreciate you taking the time to help, thank you.

Indeed I tried running another executable bin in our Dockerfile command:

[...]
CMD ["tsc", "--noEmit"]

for example and it failed too so our problem is not related to react-dsfr.

100% agree with you on that production Dockerfile. However we intended this one to be used in dev mode so everyone in the team can run it no matter their OS.
For now, everyone on the team is working on a *nix system so we might drop this Dockerfile.dev (as it should be named :))

Anyway, thanks again for taking the time 🙏

[garronej]

100% agree with you on that production Dockerfile. However we intended this one to be used in dev mode so everyone in the team can run it no matter their OS.

Ahh ok, my bad, didn't think of that. It makes sence.

Let me know if I can do something for you