Blank map after removing react-scripts / CRA and upgrading to Vite

[JamesRexMiller4]

Hello,

I am not sure if here is the best place or the mapbox-gl repository but figured I'd ask just in case someone had come across a similar issue.

The issue is that after upgrading to Vite, React 18, and removing react-scripts, the map from mapbox no longer shows up. I get the watermark and can see the elements in the DOM but just gray blankness.

There was a similar issue experienced when the project was a Create-React-App that used mapbox-gl, deck.gl, and React 16. The solution found was related to Webpack and involved importing the MapboxGLWorker and assigning it to the mapboxgl.worker class

import mapboxgl from "mapbox-gl"; import MapboxGLWorker from "mapbox-gl/dist/mapbox-gl-csp-worker?worker"; mapboxgl.workerClass = MapboxGLWorker;

I believe this solution is no longer applicable as the move to Vite means Webpack is no longer involved. I reached out to the Vite maintainers to see if they had any ideas on how to configure Vite to allow a similar workaround but they suggested asking around as likely someone else has experienced this issue. My best guess is this is a transpilation or esmodule issue, but my attempts at configuring Vite with Babel plugins did not seem to have any impact.

There is no error message in the console or terminal to provide a clue. So it's possible that the above statement doesn't even apply for the current issue. I just recall that the symptoms were similar and scouring github issues / pr's have pointed to transpilation being related.

Here is my current package.json

"deck.gl": "8.9.0",
"mapbox-gl": "3.3.0",
"react": "18.2.0",
"react-dom": "18.2.0",
"react-map-gl": "7.1.7",
"vite": "^5.0.12"
"@vitejs/plugin-react": "^4.2.1",

If anyone has experienced this or knows what may be going awry I would greatly appreciate any guidance. I can try to provide further information if that may help, but this is basically the gist of it.

[Pessimistress]

Either it's a tranpilation or CSP issue, you should see an error in the console. I can't tell from your description what the cause of your problem is, or what you are trying to achieve with the workaround code.

All of the examples in this repo and deck.gl use vite and React 18.

[JamesRexMiller4]

Apologies on the lack of details / code samples and thanks for the quick reply! I believe it is a transpilation issue as well. I don't know how but I am getting no errors in the browser console or in the terminal. The workaround that I shared I think was aimed at opting out of Webpacks transpilation of the mapbox module iirc.

Found this example for an angular setup that seemed to try to update the workaround for Vite which required a slightly different import syntax. Clearly not apples to apples because this got me nowhere

angular/angular-cli#27378

Last time I took a crack at resolving this I was trying to configure all manner of babel presets / plugins to the vite config. Maybe it's something super obvious that I am blindly looking over.

Mentioned the React 18 mostly just to denote that it went from a working setup with React 16 / create-react-app to the React 18 and Vite and if possibly react-scripts being stripped played a part in it.

[JamesRexMiller4]

The only other wrinkle that might be worth mentioning is one of the other dependencies I have is a component library that relies on React's old render method which forces my application to revert to React 17 despite using react 18.2.0 and react-dom 18.2.0

Reviewed the getting-started examples in the repo and the vite.config.js and the app.jsx components look fairly straightforward -- they just work. Given that and the fact that internet searches have been drawing blanks its gotta be something specific to my setup (sigh)

Actually looks like there is one vite.config that is more involved

`
import {defineConfig} from 'vite';
import {join} from 'path';

const rootDir = join(__dirname, '..');

/** https://vitejs.dev/config/ */
export default defineConfig(async () => {
return {
resolve: {
alias: {
// Use root dependencies
'react-map-gl': join(rootDir, './src/index.ts'),
'mapbox-gl': join(rootDir, './node_modules/mapbox-gl/dist/mapbox-gl-dev.js'),
'maplibre-gl': join(rootDir, './node_modules/maplibre-gl/dist/maplibre-gl-dev.js'),
react: join(rootDir, './node_modules/react'),
'react-dom': join(rootDir, './node_modules/react-dom')
}
},
define: {
'process.env.MapboxAccessToken': JSON.stringify(process.env.MapboxAccessToken)
},
server: {
open: true,
port: 8080
},
optimizeDeps: {
esbuildOptions: {target: 'es2020'}
}
};
});
`

I know Vite will convert dependencies to ESModules to improve performance, and was assuming something like that was happening to mapbox-gl and thus needed to opt out similar to Webpack workaround.

My Vite config requires the react() plugin since its converted from create-react-app but otherwise fairly bare bones

`
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
// import viteTsconfigPaths from "vite-tsconfig-paths";

export default defineConfig({
base: "",
plugins: [react()],
server: {
open: true,
port: 3000,
},
});

`

[Pessimistress]

I am skeptical of your claim because the page would always throw an error (xx is undefined specifically) had it been a transpilation issue.

Alas, if you still want to try apply the worker thing, you probably should set mapLib to your modified mapboxgl instead of using the default value (import('mapbox-gl')).

[JamesRexMiller4]

Sorry for the slow reply, but did find the source of the issue. Your intuition was correct in it not being a transpilation issue. In the end it was CSS reset styling declaration giving the canvas element a style of display: none 🙃

Odd part is that the styling declaration has been in there for a little over three years, so wasn't immediately apparent that that would have been the issue since I'd been working with Mapbox/react-map-gl/deck.gl for almost as long and never had an issue. The styling declaration was in the index.css file so I am thinking that Vite must be bundling the css files in a different order, where some cascading canvas declaration was previously covering up this conflict.

In hindsight, makes more sense that there was no console error. I was misdiagnosing the situation from my experience with the aforementioned web worker fix.

In any case, thank you very much for your willingness to help. It is only by standing on your shoulders that I am able to see