Error resolving preset within config file #1221
Comments
|
I don't think this isn't related to recursive symlinks. It wouldn't get that far to loading the config file. Any chance you could post the config file (even if the package name is redacted)? |
|
Ooh also do you have a typescript config file with path mappings in the project? |
To clarify, the config file itself is not accessed via a symlink. It's a path in the
It looks something like this:
I do. I tried removing them and also adding an explicit mapping for the preset file, but didn't get a difference in behavior. Happy to try something else, if needed. |
|
So I tracked the error in Node so I could understand what the exact requirements are for the validated path because it's obviously getting a string (or at least it prints as one) and it seems like the path itself can't include a null byte regardless of it being a string or UInt8Array. It would be super weird that the path has one in it but I can't think of another reason it'd fail. Any chance you're on on Windows? Also what version of the extension are you using? |
I'm on macOS 15.3.1 running version I tried playing around with the path string. It's cut off in the error log, but the full path contains a "#" character. When I remove that character, I no longer get the error. At this point, this feels more like a bug with pnpm or node. |
|
I suspect |
OOOH! Yep. This might a problem with enhanced-resolve. It allows escaping # characters with \0 (no idea why) but afaik it's not supposed to return paths with a NUL byte. Lemme look into this. https://github.com/webpack/enhanced-resolve?tab=readme-ov-file#escaping |
|
Oh literally says it right there in the readme…
So I guess this is something we've got to handle on our side. Fun. |
thecrypticace
added
bug
|
The fix will go out in the next release — probably Monday or Tuesday. 👍 |
|
@thecrypticace, can we reopen this issue? I'm getting the same stack trace after updating the plugin to Looking at the test in the PR, I think I see the difference. It's testing a direct file path while my use-case is going through the module resolver. I have a patch with a failing test: test-resolver.patch.diff.zip. If you edit file paths to remove the "#", it passes -- so I believe it's exercising the right functionality. Also including the test in plain text in case you don't want to open a zip file: Test codedefineTest({
name: 'v3: Presets with a `#` in the resolved name are loadable',
fs: {
'package.json': json`
{
"dependencies": {
"tailwindcss": "3.4.17",
"preset": "file:./a#b.js"
}
}
`,
'tailwind.config.js': js`
module.exports = {
presets: [require('preset').default]
}
`,
'a#b.js': js`
export default {
plugins: [
function ({ addUtilities }) {
addUtilities({
'.example': {
color: 'red',
},
})
}
]
}
`,
},
prepare: async ({ root }) => ({ client: await createClient({ root }) }),
handle: async ({ client }) => {
let document = await client.open({
lang: 'html',
text: '<div class="example">',
})
// <div class="example">
// ^
let hover = await document.hover({ line: 0, character: 13 })
expect(hover).toEqual({
contents: {
language: 'css',
value: dedent`
.example {
color: red;
}
`,
},
range: {
start: { line: 0, character: 12 },
end: { line: 0, character: 19 },
},
})
},
}) |
|
@nwhittaker The above test fails for a different reason. That's an invalid package definition because apparently npm doesn't support
I'm not sure what case your situation is hitting. The only uses of the resolver now replace Lemme think on this some… |
|
Oh also @nwhittaker it looks like from the error message that the NUL byte is… in the name of the config file itself. That seems super weird. |
|
Ah I think I might know what it is |
Agreed, that's just me contriving the file path. In reality it looks more like |
In reality I have the "#" appearing in the dep's directory path, not its file name. Not sure if that makes a difference here, though… |
ooooooooh okay… 🤔 I think I know what the problem is (the |
|
Okay, I figured out a way to test it. Got a PR open. Will get it merged in the am. |
|
That release should be out now. I really hope this works lol |
|
Looks to be working great now! Thanks for the quick fixes. |
Possibly related to #1185. The plugin is throwing an error during initialization. It appears to no longer be able to follow one of the
presetpaths.The project is in a monorepo using pnpm to manage dependencies. The preset file exists as a dependency of the parent project. The tailwind config exists in a child project. As a result, the child project's dependency is a symlink to the parent project's dependency.
The underscores in the stack trace are placeholders to privatize the name of the dependency while maintaining the line length.
The text was updated successfully, but these errors were encountered: