Feat: configurable known js source extensions #3219
Conversation
| // update known js src extensions | ||
| config.knownJsSrcExtensions?.forEach((ext) => | ||
| KNOWN_JS_SRC_EXTENSIONS.add(ext.startsWith('.') ? ext : `.${ext}`) | ||
| ) |
There was a problem hiding this comment.
I think we shouldn't modify KNOW_JS_SRC_EXTENTIONS here, but create a new knownJsSrcExtensions entry in ResolvedConfig that have both the default plus the added by plugins. You should be able to run Vite build programmatically with different plugins without interfering with each other (I have doubts about the cache, but for the rest, it should be independent). This would imply that we have to pass this to isJsRequest, I hope there isn't that much wiring to do.
There was a problem hiding this comment.
that wiring was the reason i resorted to this. but you're right that modifying that isn't stable esp. if config changes. Should it be a string array in the ResolvedConfig or a Set or should ResolvedConfig have a isJSRequest function (like assetsInclude already is)
Shinigami92
added
the
p2-nice-to-have
| '.vue', | ||
| '.marko', | ||
| '.svelte' |
There was a problem hiding this comment.
When we published this feature we could contact the vue, marko and svelte plugin owners and ask for that they add their extensions via their plugins
Then later on we should remove these framework extensions from Vite core
There was a problem hiding this comment.
Yes, ultimately that is the goal. For now i kept them because it requires plugin support and users updating said plugins. Maybe they should be marked as deprecated and removed with the next major only.
As this hasn't been widely used and if we coordinate it correctly with the plugins removal can happen sooner 🤔
There was a problem hiding this comment.
We are going to release a minor version in around 10 days, we may be able to do it there. I think maybe we could deprecate them in v2.3 and wait til v2.4 to remove them.
There was a problem hiding this comment.
@patak-js let the plugin-owners and the eco-system catch up and remove them in e.g. vite 2.6+
|
updated implementation to pass config.knownJsSrcExtensions into isJSRequest in #3828 |
Description
Introduce a config option to allow plugins/users to contribute to the logic of vites
isJSRequestutilsee discussion here #2829
As this option is primarily aimed at plugin authors i didn't add documentation to the user docs. Can be done if needed/wanted
This PR is also a first step in a series that would have to be taken to allow current and future SFC style plugins to configure vite without relying on the help of vite internals. The discussion linked above highlights other areas that are also in need of configurability
Additional context
The current implementation of
isJSRequestreturns true forfoo.txt?bar=.jsbecause it ended with.jsandcleanUrlwas called after the regex check. If that semantic was on purpose it could be added back by constructing a similar regex out of the SetWhat is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123).