The Vite bundler is choking on a number of plugins on account of not supporting jsx
syntax in .js
files. I have a fix but the vite.config.tsx
file I’m defining and including in tsconfig.json
doesn’t appear to be having an effect
This topic has been created from a Discord post (1239540377711542323) to give it more visibility.
It will be on Read-Only mode here.
Join the conversation on Discord
Need more info, can you share your vite config please? as well as the name & the path to it 
the name of it is vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
export default defineConfig({
plugins: [
react(),
],
esbuild:{
loader: "tsx", // OR "jsx",
include: [
// Add this for business-as-usual behaviour for .jsx and .tsx files
"src/**/*.jsx",
"src/**/*.tsx",
"node_modules/**/*.jsx",
"node_modules/**/*.tsx",
// Add the specific files you want to allow JSX syntax in
"node_modules/@offset-dev/strapi-calendar/admin/src/pages/app.js",
// "node_modules/bad-jsx-in-js-component/index.js",
// "node_modules/bad-jsx-in-js-component/js/BadJSXinJS.js",
// "node_modules/bad-jsx-in-js-component/ts/index.ts",
// "node_modules/bad-jsx-in-js-component/ts/BadTSXinTS.ts",
// --- OR ---
// Add these lines to allow all .js files to contain JSX
"src/**/*.js",
"node_modules/**/*.js",
// Add these lines to allow all .ts files to contain JSX
"src/**/*.ts",
"node_modules/**/*.ts",
]
}
})
The original error is
RollupError: Expression expected in node_modules/@offset-dev/strapi-calendar/admin/src/pages/app.js
which seems like it’s not expecting jsx
, so the fix is the following vite.config.ts
in the root folder of the application
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
export default defineConfig({
plugins: [
react(),
],
esbuild:{
loader: "tsx", // OR "jsx",
include: [
// Add this for business-as-usual behaviour for .jsx and .tsx files
"src/**/*.jsx",
"src/**/*.tsx",
"node_modules/**/*.jsx",
"node_modules/**/*.tsx",
// Add the specific files you want to allow JSX syntax in
// "node_modules/bad-jsx-in-js-component/index.js",
// "node_modules/bad-jsx-in-js-component/js/BadJSXinJS.js",
// "node_modules/bad-jsx-in-js-component/ts/index.ts",
// "node_modules/bad-jsx-in-js-component/ts/BadTSXinTS.ts",
// --- OR ---
// Add these lines to allow all .js files to contain JSX
"src/**/*.js",
"node_modules/**/*.js",
// Add these lines to allow all .ts files to contain JSX
"src/**/*.ts",
"node_modules/**/*.ts",
]
}
})
isnt your issue then that none of those paths have admin
prepended to them?
tbh, i’d just change the file type to jsx
but if you really want to do it, i’ve had better experience with the first answer in stack overflow
shouldn’t this handle it?:
// Add these lines to allow all .js files to contain JSX
"src/**/*.js",
"node_modules/**/*.js",
maybe it has the wrong CWD?
what happens when you try to build with the debug flag?
The module that handles this is strapi/packup
that sets configFile
as false
when it generates the Vite config.
It says in the documentation that you should be able to use a packup.config.ts
file to export plugins for Vite to use, but I don’t think it checks up as far as the application folder.
Sorry so to be clear, your using vite in your application, that’s importing a selection of local plugins that are using JS over JSX? are you trying to build those local plugins? Sorry, with this new information your set up is ambiguous to me, can you explain what you’re trying to achieve and how it’s set up in detail please? 
I’m trying to poke strapi 4 to load the marketplace plugins successfully using the vite bundler.
so these plugins are from NPM not ones you’ve developed?
so you need esbuild therefore, to transform code from your node_modules
There’s at least 3 busted in the same way: using js
rather than jsx
Have you reported that to the maintainers?
You probably need to do something more advanced like this solution – How to use `.js` instead of `.jsx` · vitejs/vite · Discussion #3448 · GitHub but the filter will need to change because you need to target your node_modules
.
I don’t know how many hurdles are the other side of that, so I’m going to back down.
we used it internally before doing a quick change all and it worked nicely, but that was on the library level not necessarily on the bundler for the app level.