feat(define-macros-order): add defineExposeLast option

[waynzh]

will close #2235

I'll be thankful for any suggestions on these TODOs.

• open to suggestions for a better option name…
• should we include defineExpose within the order schema? There is a potential conflict in the options, like:
  { order: ['defineExpose', 'defineProps'], defineExposeLast: true }.
• any other test cases should we add to verify the fixer?
• update the docs.

[FloEdelmann]

Thanks, this looks really good to me! 🙂

I couldn't come up with a better option name. I shortly thought about extending it to an array (something like orderLast), but I'm not sure if that's worth the effort or if defineExpose is the only macro for which it makes sense to put it at the end.

[waynzh]

I shortly thought about extending it to an array (something like orderLast)

Introducing a new orderLast array property or placing defineExpose into the order schema might potentially lead to configuration conflicts, like { order: ['defineExpose', 'defineProps'], anotherPropertyMarksExposeLast }. I was at a loss as to how to deal with these conflicts, so I chose to add a new boolean property specifically for the 'defineExpose' macro.

if defineExpose is the only macro for which it makes sense to put it at the end

In my personal practice, yes.
If it makes sense, I'll go ahead and update the test case and docs ASAP🤖

[FloEdelmann]

Introducing a new orderLast array property […] might potentially lead to configuration conflicts

If we'd introduce that orderLast option, we should validate the options so that a property can only be specified in either order or orderLast, so that wouldn't be a problem.

But if defineExpose is the only macro for which it makes sense to put it at the end anyway, I think defineExposeLast is fine.

[waynzh]

Putting defineExpose or other macros at the front can be understood as it aids in better understanding the current component. But if it's mandatory to place it at the end, it feels like only defineExpose is reasonable.

we should validate the options

Just curious, are there similar references that need to be restricted in the options? I'm not sure whether to enforce this in the JSON schema or to trigger an error in the code logic.🤔

[FloEdelmann]

are there similar references that need to be restricted in the options?

It's not possible in JSON schema. And it looks like we don't already do the same in another rule. But we could either throw an error, or just ignore values in orderLast that are already part of order.

[FloEdelmann]

LGTM, thanks! 🙂

[ota-meshi]

I think that probably shouldn't support auto-fix. It may break user's code.

<script setup>
let a = 1
defineExpose({a})
a = 2
</script>

What do you think about supporting suggestions instead?

[waynzh]

Sorry for the late response. It seems reasonable to me not to support auto-fix, thanks for pointing out!
I'll add to suggestion and refine the test cases.

[ota-meshi]

LGTM! Thank you!