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.

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

Already on GitHub? Sign in to your account

fix: 馃悰 define plugin not ignore file names #6340

Merged
merged 6 commits into from Mar 3, 2022

Conversation

Dunqing
Copy link
Contributor

@Dunqing Dunqing commented Dec 31, 2021

Description

fixes: #6295

When we use import * as from "CONSTANTS" or export * from "xxxx/CONSTANTS" statements, define plugin will replace CONSTANTS, This behavior is incorrect.

I add some boundary processing to solve this problem, it is not allowed to replace variables when there are "double quotes, single quotes, back quotes, slashes" in front of the CONSTANTS.

Additional context


What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

Before submitting the PR, please make sure you do the following

  • Read the Contributing Guidelines.
  • Read the Pull Request Guidelines and follow the Commit Convention.
  • Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
  • Ideally, include relevant tests that fail without this PR but pass with it.

Copy link
Member

@bluwy bluwy left a comment

Choose a reason for hiding this comment

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

This seems to partially fix #6340. Another case mentioned was with:

import __SOME_VAR__ from "./something"

and

export { __SOME_VAR__ }

These are rare cases though which can be handled in other PRs. Side note: I'm hoping we're not re-inventing @rollup/plugin-replace here 馃槄

Comment on lines 71 to 73
// Do not allow preceding '.', but do allow preceding '...' for spread operations
'(?<!(?<!\\.\\.)\\.)\\b(' +
Object.keys(replacements)
.map((str) => {
return str.replace(/[-[\]/{}()*+?.\\^$|]/g, '\\$&')
})
.join('|') +
// prevent trailing assignments
')\\b(?!\\s*?=[^=])',
`(?<!${characters})(?<!(?<!\\.\\.)\\.)\\b(${replacementsStr})\\b(?!${characters})(?!\\s*?=[^=])`,
// prevent trailing assignments
Copy link
Member

Choose a reason for hiding this comment

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

I think we should try to split this regex to multiple lines so the comments match, and would be more readable too.

@@ -59,16 +59,18 @@ export function definePlugin(config: ResolvedConfig): Plugin {
...processEnv
}

const characters = '[\'"`\\/]'
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
const characters = '[\'"`\\/]'
const characters = '[\'"`\\/_-]'

For example, the following code

import * from "xxxx/xx(_|-)PATH

@Dunqing
Copy link
Contributor Author

Dunqing commented Jan 1, 2022

This seems to partially fix #6340. Another case mentioned was with:

import __SOME_VAR__ from "./something"

and

export { __SOME_VAR__ }

These are rare cases though which can be handled in other PRs. Side note: I'm hoping we're not re-inventing @rollup/plugin-replace here 馃槄

In my opinion, rare cases can only be solved by ast, but the performance will be reduced, so we can only consider most cases馃槅

@bluwy
Copy link
Member

bluwy commented Jan 1, 2022

In my opinion, rare cases can only be solved by ast, but the performance will be reduced, so we can only consider most cases

You're right. I'm trying to think of ways to solve those cases, and there would always be edge cases around it unless we have the AST. I'd agree that we should keep it simple then and don't handle those.

To be fair, also handling define for filenames feels like an edge case too that can (slightly) hurt performance. Chances of this happening sounds really small, as file names are usually ./foo/bar and not __FOO_BAR__. Don't take this in a bad way though 馃槄 But I'm a bit skeptical if we do need this.

@Dunqing
Copy link
Contributor Author

Dunqing commented Jan 1, 2022

You're right. I'm trying to think of ways to solve those cases, and there would always be edge cases around it unless we have the AST. I'd agree that we should keep it simple then and don't handle those.

To be fair, also handling define for filenames feels like an edge case too that can (slightly) hurt performance. Chances of this happening sounds really small, as file names are usually ./foo/bar and not __FOO_BAR__. Don't take this in a bad way though 馃槄 But I'm a bit skeptical if we do need this.

You're right, too.
We might need a delimiters option like @rollup/replace-plugin, but that might increase the cost of using it.

bluwy
bluwy previously approved these changes Jan 1, 2022
Copy link
Member

@bluwy bluwy left a comment

Choose a reason for hiding this comment

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

Putting my approval as the code looks good to me. But my question still stands that whether we want to cover this extra edge case.

@gluck
Copy link
Contributor

gluck commented Jan 3, 2022

This PR ssems to fix some weird behavior I highlighted in this discussion: #5725
E.g. no longer replacing values in string (well at start/end of string at least, but I agree it's difficult to do better without AST)

Maybe update the define docs (docs/config.index.md) to reflect the change ?

@patak-dev
Copy link
Member

We can discuss this one in the next team meeting, but as you are already discussing, we are going to end up with a never-ending game of updating the regex and fixing "bugs". The docs state that you should use unique values like __MY_VERY_UNIQUE_CONSTANT__ as define is a simple replace operation so we need to place the limit somewhere and stick with it.

@patak-dev patak-dev added the p3-minor-bug An edge case that only affects very specific usage (priority) label Feb 13, 2022
@patak-dev patak-dev added the inconsistency Inconsistency between dev & build label Feb 25, 2022
@patak-dev patak-dev added this to the 2.9 milestone Feb 25, 2022
@patak-dev
Copy link
Member

@1247748612 we talked about this PR today and we decided that we should merge this fix. Thanks for looking into the issue. We should wait until the 2.9 beta window (probably starting next week) so we get some extra testing. Would you check the conflicts in the PR?

@Dunqing
Copy link
Contributor Author

Dunqing commented Feb 26, 2022

@1247748612 we talked about this PR today and we decided that we should merge this fix. Thanks for looking into the issue. We should wait until the 2.9 beta window (probably starting next week) so we get some extra testing. Would you check the conflicts in the PR?

Thanks to the team for the discussion on this pr, I have resolved the conflict. I may also need to add some test cases for this pr.

@patak-dev
Copy link
Member

Thanks again. I think the added test cases are enough to merge it but welcome to add more cases and improve the suite

@patak-dev patak-dev merged commit 7215a03 into vitejs:main Mar 3, 2022
@Dunqing Dunqing deleted the fix/define-plugin-ignore branch March 3, 2022 09:20
patak-dev added a commit to dominikg/vite that referenced this pull request Mar 4, 2022
patak-dev added a commit that referenced this pull request Mar 4, 2022
Co-authored-by: patak-dev <matias.capeletto@gmail.com>
@patak-dev
Copy link
Member

@1247748612 we are reverting this PR as it causing regressions in Svelte and Vitest. We could work in another PR to implement this feature, but we should see how to simplify the regex and add more tests before moving forward. Thanks again for your work exploring this solution.

@Dunqing
Copy link
Contributor Author

Dunqing commented Mar 8, 2022

@1247748612 we are reverting this PR as it causing regressions in Svelte and Vitest. We could work in another PR to implement this feature, but we should see how to simplify the regex and add more tests before moving forward. Thanks again for your work exploring this solution.

I don't know why this is causing this, I'll try to fix it and submit the pr again after simplifying the regex. Thanks you again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inconsistency Inconsistency between dev & build p3-minor-bug An edge case that only affects very specific usage (priority)
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Define global constant replacements should ignored filename
5 participants