Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix: dont replace define in json #7294

Merged
merged 1 commit into from Mar 12, 2022
Merged

fix: dont replace define in json #7294

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
1 change: 1 addition & 0 deletions packages/playground/define/__tests__/define.spec.ts
View file
Open in desktop
Expand Up @@ -22,4 +22,5 @@ test('string', async () => {
)
// html would't need to define replacement
expect(await page.textContent('.exp-define')).toBe('__EXP__')
expect(await page.textContent('.import-json')).toBe('__EXP__')
})
3 changes: 3 additions & 0 deletions packages/playground/define/data.json
View file
Open in desktop
@@ -0,0 +1,3 @@
{
"foo": "__EXP__"
}
4 changes: 4 additions & 0 deletions packages/playground/define/index.html
View file
Open in desktop
Expand Up @@ -10,6 +10,7 @@ <h1>Define</h1>
<p>spread object: <code class="spread-object"></code></p>
<p>spread array: <code class="spread-array"></code></p>
<p>define variable in html: <code class="exp-define">__EXP__</code></p>
<p>import json: <code class="import-json"></code></p>

<script type="module">
const __VAR_NAME__ = true // ensure define doesn't replace var name
Expand All @@ -28,6 +29,9 @@ <h1>Define</h1>
)
text('.spread-array', JSON.stringify([...`"${__STRING__}"`]))

import dataJson from './data.json'
text('.import-json', dataJson.foo)

function text(el, text) {
document.querySelector(el).textContent = text
}
Expand Down
4 changes: 4 additions & 0 deletions packages/vite/src/node/plugins/define.ts
View file
Open in desktop
Expand Up @@ -5,6 +5,9 @@ import type { Plugin } from '../plugin'
import { isCSSRequest } from './css'
import { isHTMLRequest } from './html'

const nonJsRe = /\.(json)($|\?)/
const isNonJsRequest = (request: string): boolean => nonJsRe.test(request)

export function definePlugin(config: ResolvedConfig): Plugin {
const isBuild = config.command === 'build'

Expand Down Expand Up @@ -99,6 +102,7 @@ export function definePlugin(config: ResolvedConfig): Plugin {
// exclude html, css and static assets for performance
isHTMLRequest(id) ||
isCSSRequest(id) ||
isNonJsRequest(id) ||
config.assetsInclude(id)
Comment on lines 102 to 106
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should go the other way around and use the isJSRequest(id) utility here. This isn't only for performance, if we want to avoid inconsistencies between dev and build, we shouldn't be doing replacements for define in non-js sources.
I think we can merge your PR now to close the issue, but let's explore this further.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've thought about it too but it feels like a bold move that could cause a breaking change if there are more extensions that compile to JS (Vite currently keeps a hardcoded list for it). And I can see some cases for this, like .svelte.md which is compiled by Svelte but is written in markdown.

Maybe the more robust way is to somehow identify the code is JS and then do the replacements. Or otherwise we can proceed with #3828 to make things more flexible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, #3828 got stuck because we thought there was a chance of removing this list altogether but there hasn't been progress in that direction and this is another valid use case for being able to answer the "isJSRequest" question. Maybe we should push for #3828 again.

) {
return
Expand Down