Path includes a dot (.) character

[maratnasyrov]

Describe the bug

When trying to load styles from a file from another library using @vanilla-extract/vite-plugin, an error occurs on the dev server:
vite:spa-fallback Not rewriting GET /@id/ComponentsApp/src/components/Button/styles.css.ts.vanilla.css?hash=0b6a2903c4458e87f00567205ad0a3b6 because the path includes a dot (.) character.

This only occurs if you install the library from the local repository.

At first I thought that the problem might be in the plugin itself, but after debugging I realized that the following path is passed to the @vanilla-extract/vite-plugin for exporting styles:
These two points cause this error
MainApp/../ComponentsApp/src/components/Button/styles.css.ts.vanilla.css?source=LnN0eWxlc19fN3ltc2N6MCB7CiAgY29sb3I6ICNmZjAwMDA7CiAgZm9udC1zaXplOiAyMHB4Owp9

Reproduction

git clone [email protected]:maratnasyrov/ComponentsApp.git
git clone [email protected]:maratnasyrov/MainApp.git
cd MainApp
npm install -S ../ComponentsApp
npm run dev
Open localhost:3000 in browser

Also, this error can be seen in the console

System Info

System:
    OS: Linux 5.4 Ubuntu 20.04.2 LTS (Focal Fossa)
    CPU: (4) x64 Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz
    Memory: 413.61 MB / 15.58 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 14.17.3 - ~/.nvm/versions/node/v14.17.3/bin/node
    Yarn: 1.17.3 - /usr/bin/yarn
    npm: 6.14.13 - ~/.nvm/versions/node/v14.17.3/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Browsers:
    Chrome: 92.0.4515.107
    Firefox: 90.0.2

Used Package Manager

npm

Logs

vite:load 0ms   [fs] ../ComponentsApp/src/components/Button/styles.css.ts +43ms
  vite:resolve 1ms   MainApp/../ComponentsApp/src/components/Button/styles.css.ts.vanilla.css?source=LnN0eWxlc19fMXVoNTl2MjAgewogIGNvbG9yOiAjZmYwMDAwOwogIGZvbnQtc2l6ZTogMjBweDsKfQ== -> MainApp/../ComponentsApp/src/components/Button/styles.css.ts.vanilla.css?hash=6785b7839a3057ae265165081227272a +62ms
  vite:resolve 1ms   /@id/ComponentsApp/src/components/Button/styles.css.ts.vanilla.css?hash=6785b7839a3057ae265165081227272a -> null +1ms
  vite:transform 43ms  ../ComponentsApp/src/components/Button/styles.css.ts +60ms
  vite:time 45ms  ../ComponentsApp/src/components/Button/styles.css.ts +59ms
  vite:resolve 1ms   ComponentsApp/src/components/Button/styles.css.ts.vanilla.css?hash=6785b7839a3057ae265165081227272a -> null +12ms
  vite:spa-fallback Not rewriting GET /@id/ComponentsApp/src/components/Button/styles.css.ts.vanilla.css?hash=6785b7839a3057ae265165081227272a because the path includes a dot (.) character. +838ms
  vite:time 3ms   /@id/ComponentsApp/src/components/Button/styles.css.ts.vanilla.css?hash=6785b7839a3057ae265165081227272a +13ms

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[Kashuab]

+1

In my case, I need to parse a JWT from the URL which is part of the path. For example:

http://localhost:4000/some-path/ag348g9ha3e48rhgalsdkf.f23agw4eg89asdhg.Ddufasfmwi9o0efjnE

In the meantime, I'll try to convince my colleagues to use a query string instead 😄

[ygj6]

Duplicate of #4344

[ygj6]

First, I apologize that I mistakenly marked it as a duplicate at the beginning.

I tested this issue and only the npm installed dependencies have this problem, the yarn installed dependencies do not have this problem.

Because vite resolves the locally installed ComponentsApp dependencies to different paths：

vite/packages/vite/src/node/plugins/resolve.ts

Lines 491 to 505 in 0aaca23

	export function resolvePackageData(
	id: string,
	basedir: string
	): PackageData | undefined {
	const cacheKey = id + basedir
	if (packageCache.has(cacheKey)) {
	return packageCache.get(cacheKey)
	}
	try {
	const pkgPath = resolveFrom(`${id}/package.json`, basedir)
	return loadPackageData(pkgPath, cacheKey)
	} catch (e) {
	isDebug && debug(`${chalk.red(`[failed loading package.json]`)} ${id}`)
	}
	}

local dependency for the yarn installation, obtained by resolve, is a link address:
root/MainApp/node_modules/ComponentsApp/src/index.ts

and the local dependencies installed by npm get a real address:
root/ComponentsApp/src/index.ts

this causes the transform hook that triggers @vanilla-extract/vite-plugin to parse @vanilla-extract/css as:
MainApp/../ComponentsApp/src/components/Button/styles.css.ts.vanilla.css?source=LnN0eWxlc19fMXVoNTl2MjAgewogIGNvbG9yOiAjZmYwMDAwOwogIGZvbnQtc2l6ZTogMjBweDsKfQ==

later, when entering the resolveId hook of @vanilla-extract/vite-plugin, the path above is used as the key to store static CSS code, but Vite normalizes this path before the end of the resolveId hook as follows:

vite/packages/vite/src/node/server/pluginContainer.ts

Lines 468 to 471 in 0aaca23

	if (id) {
	partial.id = isExternalUrl(id) ? id : normalizePath(id)
	return partial as PartialResolvedId
	} else {

the path becomes:
root/ComponentsApp/src/components/Button/styles.css.ts

this leads to later loading the style with the load hook, using the normalized path as the key to get the static CSS code, which is inconsistent with the code used when storing, so it cannot be found and eventually leads to a 404.

I will submit a pr in the @vanilla-extract/vite-plugin community to fix this issue. This issue I marked as upstream because I think normalization can avoid a lot of security issues, so we should normalize the path.

[maratnasyrov]

@ygj6 thanks for your quick response and analysis of this problem. I have not tried using yarn in this case yet, but I think it might be a temporary solution until your changes in vanila-extract are published.

[ygj6]

@ygj6 thanks for your quick response and analysis of this problem. I have not tried using yarn in this case yet, but I think it might be a temporary solution until your changes in vanila-extract are published.

PR has been merged and @vanilla-extract/vite-plugin has released 1.1.2 version, I tested it and the issue has been solved, you can try it.
https://github.com/seek-oss/vanilla-extract/releases/tag/%40vanilla-extract%2Fvite-plugin%401.1.2

[mseele]

Checkout vite plugin https://github.com/ivesia/vite-plugin-rewrite-all
This should fix the problem (see also #2190)