fix(less): prevent rebasing @import url(...)

[smeng9]

Description

Closes #13143

Since we called the rebaseUrls functions to rebase everything to the root file,
Next time when we use resolvers.less we must also pass the root file instead of the current dir.

Used a different method to fix the issue. See below.

EDIT @bluwy: description of issue at #17857 (comment)

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[smeng9]

Still needs a test case

[smeng9]

However after the import in line 2535 we rebased the url to the rootfile. Do you mean we should rebase the file to the current file instead of rootfile? Then next time the file name will be relative to the file that imports it instead of relative to the root file. Get Outlook for iOS<https://aka.ms/o0ukef>

________________________________ From: Bjorn Lu ***@***.***> Sent: Wednesday, August 14, 2024 2:03:01 AM To: vitejs/vite ***@***.***> Cc: Meng, Shaoyu ***@***.***>; Author ***@***.***> Subject: Re: [vitejs/vite] fix(less): always use root file as base when resolving id (PR #17857) @bluwy commented on this pull request.

________________________________ In packages/vite/src/node/plugins/css.ts<https://urldefense.com/v3/__https://github.com/vitejs/vite/pull/17857*discussion_r1716565269__;Iw!!DZ3fjg!9EoFQrEdBL2JKSVtsCDryoIMd7koBPIHEaMpf1Vxm_arg5NTwH7xq3nmpqne5xPcpl3orVCRtmzZr4uiZAz5KfwW6kI$>:

- const resolved = await resolvers.less(filename, path.join(dir, '*'))

+ const resolved = await resolvers.less(filename, rootFile) I don't think this is correct? The filename should always be resolved from the file that imports it, not the rootFile. The problem I'm seeing is that Less is treating @import url() weirdly. With @import url('../../less/ommer.less'); in the test, the filename becomes less/ommer.less. But with @import '../../less/ommer.less';, filename becomes ../../less/ommer.less. I think we need to figure out why this happens first. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/vitejs/vite/pull/17857*pullrequestreview-2237574274__;Iw!!DZ3fjg!9EoFQrEdBL2JKSVtsCDryoIMd7koBPIHEaMpf1Vxm_arg5NTwH7xq3nmpqne5xPcpl3orVCRtmzZr4uiZAz5rgd0t40$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AJHAEC26KZCM7YNDRD3IPRLZRMMMLAVCNFSM6AAAAABMJQP3GOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDEMZXGU3TIMRXGQ__;!!DZ3fjg!9EoFQrEdBL2JKSVtsCDryoIMd7koBPIHEaMpf1Vxm_arg5NTwH7xq3nmpqne5xPcpl3orVCRtmzZr4uiZAz5vuOFoeU$>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[smeng9]

Rebased to fix conflicts with v6 environment api.

the @import is also used in scss, removing that line will cause scss to fail.

Ideally Vite should always be able to resolve it yes.
Shall we consider using less to resolve this file instead of using vite to resolve this file?

[smeng9]

Hi @bluwy I have used a different method from the one you suggested to solve the problem.

The relative path is not very robust, we can just choose to use the absolute path as the id for a file.

If we use absolute path, less is able resolve the file instead of falling back to vite to resolve the file

[bluwy]

Sorry for not following up on this. It required a lot of context to pick back up. I've dig into the bug again and have a better idea of the issue now.

1. We have a generic url() rebase logic, however it shouldn't rebase on @import url(...) because that gets compiled by the preprocessor straight away instead of being retained in the final single compiled file.
2. We have a @import "*.css" rebase logic to fix less/scss, because they don't compile those imports that end with .css files, so they're retained and needs rebasing. However, the regex wasn't capturing @import url(...).

The fix I made is to ensure url() rebase does not handle @import url(...). And ensure @import url(*.css) rebase gets handled. That fixed the test locally for me.

I think we should still be rebasing to relative paths to avoid unintended side-effects. Also, I think no2 handling is kinda fragile and should've been forced to be compiled by the preprocessor in the first place. The @import will get re-ordered otherwise for example. I don't know if there's a way to enable that in the preprocessors easily, but something to tackle in the future.