feat(define): prevent assignment

[bluwy]

Description

Fixes #5269
Fixes #4271
Fixes #5278
Fixes #4887

Prevent define replacement if has trailing assignments

Additional context

Should this be a new config option? It could be breaking, but in rare edge cases.

---

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.

[patak-dev]

Im not sure we should do this. The users in the linked issues should use a constant name tgat doesnt conflict with their code. With this change, the local variable isnt replaced but their use later in the scope is replaced, so potentially there could be inconsistencies because of this. IMO if wexare not going to do proper AST replacement, we should keep define simple and continue to ask users to choose non-conflicting names

[bluwy]

Wouldn't the inconsistency be intentional? I believe this is how @rollup/plugin-replace works too according to its docs example, and it's recommended true. FWIW the regex used is the same as well. I think it's still a fair change to guard users from the odd error message, and in most case the user would know the risk of using define and its inconsistency.

[patak-dev]

Thanks for the pointers @bluwy, looks like Rollup didn't change it right away to prevent a breaking change then. I would vote to add this without an option as you did in this PR to align with future versions of the official rollup define plugin (I don't think we should have the complexity of options on our side). I'll bring this PR to the next team meeting so we can discuss it there

[patak-dev]

We talked in the last team meeting about this, let's merge it in the 2.8 beta so the ecosystem has a bit of time to test it

[btea]

Perhaps the import/export variables and file names should also be ignored?

[patak-dev]

@btea would you create a new feature request or PR to discuss further changes?

[btea]

There is one more question, I don’t know if my understanding is correct.

According to the current modification, the variable declaration will be prevented from being replaced, but the use of the variable does not prevent the replacement, which will cause the packaged code to get the wrong value of the variable.

[btea]

@btea would you create a new feature request or PR to discuss further changes?

Maybe I should create a new feature to discuss it?

[bluwy]

There is one more question, I don’t know if my understanding is correct.

According to the current modification, the variable declaration will be prevented from being replaced, but the use of the variable does not prevent the replacement, which will cause the packaged code to get the wrong value of the variable.

If you mean for code like this:

const __PROD__ = false

console.log(__PROD__) // if we replace __PROD__ as true, this will log true, instead of the from the variable -- false

I think this behaviour would be intentional from the user point of view, as from the linked issues.

Perhaps the import/export variables and file names should also be ignored?

This sounds like a fair thing to support too, I think we should create a new feature issue for it.

[btea]

I think this behaviour would be intentional from the user point of view, as from the linked issues.

Yeah, you are right.

This sounds like a fair thing to support too, I think we should create a new feature issue for it.

ok.