[TurboPack] When using a custom PostCSS config, TurboPack fails to compile application on Windows #63755
Comments
pixel-toys-chris-evans
added
the
bug
pixel-toys-chris-evans
changed the title
|
For me renaming postcss.config.js to postcss.config.cjs fixed this issue. |
sokra
added
the
linear: turbopack
fixes the `ERR_UNSUPPORTED_ESM_URL_SCHEME` as suggested by vercel/next.js#63755 (comment)
|
For those who are here from search: I have just bumped into the same issue after upgrading to Next.js 14.2.0 and adding module.exports = {
plugins: {
tailwindcss: {},
autoprefixer: {},
"./my-custom-plugin.cjs": {},
},
};Output: Here is what worked for me: module.exports = {
plugins: {
tailwindcss: {},
autoprefixer: {},
- "./my-custom-plugin.cjs": {},
+ [`/${require("node:path").resolve(".")}/my-custom-plugin.cjs`]: {},
},
};Oddly enough, using |
|
It looks like this should be resolved by #64386. Thanks for reporting this issue! |
|
This is still relevant for loading the postcss.config.js, it's fixed for next.config.js loading only in #64386 |
timneutkens
changed the title
Absolute paths don't work for imports on windows because `c:\` is interpreted as a URI scheme. The workaround is to use an unambiguous `file://` URI. Fixes vercel/next.js#63755 Similar to vercel/next.js#64386
Absolute paths don't work for imports on windows because `c:\` is interpreted as a URI scheme. The workaround is to use an unambiguous `file://` URI. Fixes vercel/next.js#63755 Similar to vercel/next.js#64386
|
@pixel-toys-chris-evans I've confirmed that after updating your project to next.js 14.2.2, the issue no longer reproduces on Windows. Thanks again for submitting! |
|
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
…cel/turbo#7995) Absolute paths don't work for imports on windows because `c:\` is interpreted as a URI scheme. The workaround is to use an unambiguous `file://` URI. Fixes #63755 Similar to #64386
…cel/turbo#7995) Absolute paths don't work for imports on windows because `c:\` is interpreted as a URI scheme. The workaround is to use an unambiguous `file://` URI. Fixes #63755 Similar to #64386
…cel/turbo#7995) Absolute paths don't work for imports on windows because `c:\` is interpreted as a URI scheme. The workaround is to use an unambiguous `file://` URI. Fixes #63755 Similar to #64386
…cel/turbo#7995) Absolute paths don't work for imports on windows because `c:\` is interpreted as a URI scheme. The workaround is to use an unambiguous `file://` URI. Fixes #63755 Similar to #64386
Link to the code that reproduces this issue
https://github.com/pixel-toys-chris-evans/browserslist-file-resolution-turbo-win32
To Reproduce
--turboset on a Windows OS.Current vs. Expected behavior
Absolute paths within the built chunks are letter based which throws an error on Windows machines. This works fine for our MacOS based machines.
Windows NodeJS is expecting a
file://absolute path.Provide environment information
Which area(s) are affected? (Select all that apply)
Turbopack (--turbo)
Which stage(s) are affected? (Select all that apply)
next dev (local)
Additional context
This is not currently in the latest release, and can only be found in the Canary release. We updated due to the compilation issues with Sanity.io builds using the
--turboflag in lts that are fixed in Canary.PACK-2880
The text was updated successfully, but these errors were encountered: