Support de Turbopack sur Next 15 ?

[ToolReaz]

Bonjour,

Est-ce que cette librairie supporte l'utilisation de Turbopack dans un projet Next 15 ?

La documentation indique d'ajouter dans le next.config.js:

  webpack: (config) => {
    config.module.rules.push({
      test: /\.woff2$/,
      type: 'asset/resource',
    })
    return config
  },

Ce qui ne fonctionne plus avec Turbopack (qui supporte les fichiers .woff2 par défaut).

D'apres mes tests la libraire fonctionne mais avec des comportements étranges:

• Navigation ne s'affiche pas
• Sous menus de la navigation ne s'ouvrent pas
• Header proprieté brandTop qui ne s'affiche pas

Le support de Turbopack serait vraiment un plus, je continue mes recherches de mon coté.

[garronej]

Hello @ToolReaz,

Ce qui ne fonctionne plus avec Turbopack (qui prend en charge les fichiers .woff2 par défaut).

L’objectif est que Next comprenne qu’il doit importer les fichiers .woff2 comme des URLs :

https://github.com/codegouvfr/react-dsfr/blob/main/src/next-appdir/zz_internal/fontUrlByFileBasename.ts

C’est peut-être le cas par défaut, mais il y a probablement une option à activer pour le garantir.

D’après mes tests, la librairie fonctionne, mais avec des comportements étranges :

😩 Cela vient probablement du fait que Next ne transpile pas correctement le CSS, ce qui est un problème récurrent.

Si tu es prêt à nous aider, on peut t’onboard sur le projet !

[ToolReaz]

Re,

😩 Cela vient probablement du fait que Next ne transpile pas correctement le CSS, ce qui est un problème récurrent.

Après quelques tests je pense que c'est le JSX qui est mal transpilé... notamment cette partie là qui ne retourne rien:

// Header.tsx
{(() => {
    const children = (
        <p className={fr.cx("fr-logo")}>{brandTop}</p>
    );

    return serviceTitle !== undefined ? (
        children
    ) : (
        <Link {...homeLinkProps}>{children}</Link>
    );
})()}

En utilisant le test d’intégration next-appdir dans le repo et en le passant sous Next 14 avec Turbo cela fonctionne toujours. Ce n'est qu'a partir de la version 15 que ça casse. De même en rétrogradant mon projet vers 14 cela corrige le problème.

Je vais essayer d'identifier plus précisément la cause de la non transpilation pour éventuellement ouvrir une issue chez Next.

[garronej]

Super top merci!

[martinratinaud]

@garronej Alors j'ai aussi des problèmes et j'ai fait un repo de reproduction.
C'est vraiment très handicapant car Next chez FCU devient de plus en plus lourd à utiliser et Turbo permet de revenir à un confort de développement parfait mais le DSFR n'étant plus utilisable en l'état est problématique.

Erreur à l'utilisation 1 (solution trouvée ✅)

La première erreur trouvée est Error: Failed to load external module @codegouvfr/react-dsfr/Card.js: SyntaxError: Cannot use import statement outside a module et cela peut etre corrigé en utilisant

  transpilePackages: ['@codegouvfr/react-dsfr'],

dans next.config.ts

Erreur à l'utilisation de getLink (Besoin d'aide 🆘)

Cette erreur la est plus compliquée et reproductible ici. Cela donne ReferenceError: React is not defined et je ne trouve pas de solution, si ce n'est de

• copier le composant dans mon code
• supprimer les références à getLink (J'ai passé plusieurs heures à isoler ce problème étant donné le message très peu parlant)

je pense que cette utilisation de getLink avec setLink et un let Link est à l'origine du problème mais je ne trouve pas de solution.

Chargement des svg (solution partielle trouvée ⚠️)

par défaut, turbo n'a pas de loader pour les svg mais on peut les faire supporter par la config de cette manière

experimental: {
    turbo: {
      rules: {
        '*.svg': {
          loaders: ['@svgr/webpack'],
          as: '*.js',
        },
      },
    },
  },

Le problème est que cela va supprimer tous les svg loadés en css :-(, j'ai donc du renommer mes fichiers svg à loader directement sous forme de composant par des .svgr (extension complètement arbitraire, qui rappelle le nom du loader)

experimental: {
    turbo: {
      rules: {
        '*.svgr': {
          loaders: ['@svgr/webpack'],
          as: '*.js',
        },
      },
    },
  },

Chargement des markdown (solution trouvée ✅)

pareil

experimental: {
    turbo: {
      rules: {
         '*.md': {
          loaders: ['raw-loader'],
          as: '*.js',
        },
      },
    },
  },

[garronej]

Hello @martinratinaud,

Thanks a lot for the detailed breakdown, this kind of issue report is super helpful!

I'll look into what can be done.
But once again, Vercel is shipping half-baked features and offloading the responsibility of making things work onto the ecosystem.

Turbopack also breaks tss-react, and there’s nothing particularly unusual about it. It's ISO-compliant, shipped in both ESM and CJS formats.

I honestly don’t understand how they thought Turbopack was ready to be the default...
Well, I do get it, if you’re not on an M-series Mac, the webpack based Next dev experience feels painfully slow.

[martinratinaud]

Thanks

Well 'im on a M1 and webpack is definitely too slow on dev and causing frustration.
I agree that NextJs is definitely making it less and less interesting to use it but unfortunately, I think a lot of projects in the Beta ecosystem are using it and feel the same pain than me every day.

I checked the react-dsfr code and this whole getLink thing seems like something I never saw before in component libraries. I'm curious why it is, and how you think it can break turbopack.

Thanks

[martinratinaud]

I finally found a way out of this problematic by doing the following

1. Use aliases only for turbo and for problematic components (ones which use getLink

experimental: {
    turbo: {
      resolveAlias: {
        '@codegouvfr/react-dsfr/Breadcrumb': '@/components/turbo/Breadcrumb',
        '@codegouvfr/react-dsfr/Button': '@/components/turbo/Button',
        '@codegouvfr/react-dsfr/ButtonsGroup': '@/components/turbo/ButtonsGroup',
        '@codegouvfr/react-dsfr/Card': '@/components/turbo/Card',
        '@codegouvfr/react-dsfr/Footer': '@/components/turbo/Footer',
        '@codegouvfr/react-dsfr/Header': '@/components/turbo/Header',
        '@codegouvfr/react-dsfr/MainNavigation': '@/components/turbo/MainNavigation',
        '@codegouvfr/react-dsfr/Menu': '@/components/turbo/Menu',
        '@codegouvfr/react-dsfr/MegaMenu': '@/components/turbo/MegaMenu',
        '@codegouvfr/react-dsfr/Tile': '@/components/turbo/Tile',
      },
      rules: {
        '*.svgr': {
          loaders: ['@svgr/webpack'],
          as: '*.js',
        },
        '*.md': {
          loaders: ['raw-loader'],
          as: '*.js',
        },
      },
    },
  },

2. Create the problematic components by copy pasting from GitHub and removing the use of const { Link } = getLink() and replacing it with a standard import. Check this commit for reference

💡 And for those who wonder, it is worth it as load times are insanely faster