How to Improve Build Performance in Next.js/Webpack with @arcgis?

[JonathanDawe3]

I've been working on a project using Next.js with the ArcGIS API but ultimately reverted to using TanStack Router with Vite due to significant developer experience issues. While the production build works fine, the development process has been extremely frustrating.

Project Context

• Next.js branch:  NextJS application.  
• Vite + TanStack branch: using tanstack for routing.

Key Issues with Next.js

1. Slow development process compared to other mapping libraries – Any change to a component triggers a full rebuild, taking 40–60 seconds, and requires a manual page refresh to see updates. In contrast, Vite's dependency pre-building enables near-instant updates without a full rebuild. I've built highly interactive mapping applications with Next.js before (e.g. icelogistics.info/antarctic) using Leaflet, but the experience with ArcGIS has been significantly slower.
2. Turbopack incompatibility – Some ArcGIS packages depend on Stencil.js, which uses dynamic imports and custom Webpack comments that fail to compile in Turbopack.

Questions

• Has anyone successfully optimised the development experience of using Next.js with the ArcGIS API?
• Are there any known workarounds for handling Stencil.js dependencies in Next.js/Turbopack?
• Is there any active work being done to improve ArcGIS compatibility with frameworks like Next.js? Will this get better in the future, or would the advice be to avoid it where possible?

I’d prefer to continue using Next.js, but the current ArcGIS compatibility issues make it challenging. Any insights or workarounds would be greatly appreciated!

[Sage_Wall · Accepted solution]

Things will get better 😀.  We are migrating away from stencil for our web components beginning at version 4.32 so that should help with your Turbopack issues. We are also working on optimizing the web components to work better with frameworks.  If you use react 19 for instance you will no longer need to use the react specific wrapper, you'll be able to use the normal native web components.  I don't have any specific build optimization suggestions for you right now as I'm not all that familiar with Next.js but we are trying to make things better for framework users.

[JonathanDawe3]

Fantastic! Thats really useful information to know! Especially regarding the switch away from StencilJS... To be blunt, the majority of any build/types/testing issues I've ever seen with ArcGIS seem to have come from the Stencil JS library 😁

Regarding react 19, I made a bit of an attempt to switch over to using the web components natively already! Currently its not been super clear to me whether there is a pattern we should be following for getting the types for the web components? In fact I've been rather hamfistedly adding them in myself 😬https://github.com/JonnyDawe/UK-Sewage-Map/blob/main/src/types/global.d.ts.

This implementation gives me the allowed props, but unfortunately strips out the actual types for them (everything ends up as any)... From my investigations it looked like a StencilJS build quirk, so maybe this will also get simpler!

[Sage_Wall]

At version 4.32 (or RC currently) you'll be able to get the React types (and some other frameworks) by including them using a /// comment or you could also add the types in the includes section of your tsconfig if you wanted to do it there.

I've been adding an arcgis.d.ts file in my src folder with this in it, but that's just my preferred way not official Esri advise

/// <reference types="@arcgis/map-components/types/react.d.ts" />

 tsconfig.app.json

...,
"include": ["src", "node_modules/@arcgis/map-components/types/react.d.ts"]
...

[JonathanDawe3]

Thanks - top tier answers!