Open dvdzkwsk opened 3 years ago
@davezuko I figured out that vite will return the cached moduleroute.ts
,instead of treating the /route
as the requested path,which is unexpected.
I have submitted a pull request ,#3513
Still reproducible in Vite 2.8.6
I think it would be better to check the Accept
HTTP request header in the Vite dev server, instead of adding an explicit query parameter.
I think this "extension guessing" should be disabled or at least be made configurable to be disabled. I think it's bad practice to serve /foo.js
on route /foo
as such paths are very likely to collide with client-side routing.
I think you should be able to achieve that already using
resolve: {
extensions: []
}
Tried setting resolve.extensions = []
but I'm not sure if vite can operate with such a config. Seeing this error:
✘ [ERROR] [plugin vite:dep-pre-bundle] Failed to resolve entry for package "function-bind". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "function-bind". The package may have incorrect main/module/exports specified in its package.json.
node_modules/vite/dist/node/chunks/dep-8f5c9290.js:40945:10:
40945 │ throw new Error(`Failed to resolve entry for package "${id}". ` +
╵ ^
That function-bind
module is a eslint dependency, so it might be that the error relates to linting.
mmm... ya, maybe some dependencies expect resolution to work. This should be better once everybody starts to use the exports
field. I don't know if Vite should consider extensions
only for user code and then patch over wrongly published deps (if that is the problem here)
I think you should be able to achieve that already using
resolve: { extensions: [] }
This documentation does not appear to exist any more. Are there plans to replace it?
Describe the bug
Vite Config:
Project Structure:
A request to
/route
will unexpectedly serve/route.ts
.Since the file extension is omitted, I would expect for the traditional
connect-history-api-fallback
logic to apply and for/index.html
to be served. If wanted to load the source file I would expect to have to make an explicit request for/route.ts
. It doesn't seem right for the file extension to be inferred.This is likely more of an issue for people like me who've configured
root
since that may mean source files sit at the top-level ofroot
instead of nested inside of asrc
directory. Still, for cases such as this, this issue becomes more problematic as more source files and routes are created, since there's more opportunity for an inadvertent conflict.Important: On the first load, you will actually see the correct fallback logic. It's only once vite has processed
route.ts
that the fallback behavior changes, and you'll start seeing a JavaScript file served instead of index.html.Thanks for your help!
Reproduction
https://github.com/davezuko/reproductions/tree/master/vite-3502
Steps to reproduce:
yarn dev
http://localhost:3000
, the app loads correctlyhttp://localhost:3000/test
, the app loads correctly (renders "/test")http://localhost:3000/route
, the app serves/route.ts
http://localhost:3000/main
, the app serves/main.ts
Alternate reproduction:
yarn dev
http://localhost:3000/route
, the app loads correctlyhttp://localhost:3000/route
, the app now serves/route.ts
System Info
Output of
npx envinfo --system --npmPackages vite,@vitejs/plugin-vue --binaries --browsers
:Used package manager: yarn
Logs
Before submitting the issue, please make sure you do the following