What problem does this feature solve?

it would be great to be able to specify specific variables to disregard when showing this warning: setup() return property "_" should not start with "$" or "_" which are reserved prefixes for Vue internals

Specifically I am using lodash, so I often have something like import _ from 'lodash' in my files.

When using the options api, this isn't really a huge issue, because usually lodash functions aren't needed in the template, and renaming lodash itself or a specific function while explicitly exposing it to the template isn't too common. However with the new script setup API, this would mean having to always rename lodash itself when importing it. While that's fine, it's not great for readability when lodash being named _ is the norm.

What does the proposed API look like?

A few things come to mind that could help

• ignore the variable name _ itself from this warning
• allow users to explicitly allow specific vars that are prefixed with _ or $, similar to app.config.globalProperties but something like app.config.allowInternalPrefixSetupProps = ['_', '_myVar', '$somethingSpecial']

In practice, you should really import individual functions from lodash because of the size difference, but a compiler option would definitely help.

You are not limited by this when using <script setup> - you should probably migrate if you haven't already?

@yyx990803 - thanks, I am using script setup already. This issue has not been a blocker at all, it's just been filling my browser console with warnings. I was able to figure out how to hide it yesterday using a custom warning handler, but I still think another config setting as mentioned above could be helpful.

For anyone else finding this - here is the warning handler:

app.config.warnHandler = function (msg, vm, trace) {
  if (msg === 'setup() return property "_" should not start with "$" or "_" which are reserved prefixes for Vue internals.') return;
  console.warn(msg, trace);
};

@posva - yeah I'm aware. I personally find a single lodash import and calling _.funcName much more readable and simpler than individual imports. I'm hoping to eventually get something like https://github.com/lodash/babel-plugin-lodash set up with vite to do it automatically, but in the meantime I just have my own lodash utils file that I import instead of lodash directly:

// import all the lodash functions individually in a way that unused functions will be shaken
...
import add from 'lodash-es/add';
import after from 'lodash-es/after';
import ary from 'lodash-es/ary';
import assign from 'lodash-es/assign';
import assignIn from 'lodash-es/assignIn';
...

// export only the ones we want to keep
export default {
  assign,
 ...
}

Hmm, I don't think this should happen with <script setup> (see playground example)

Do you have a reproduction?

I found that in dev mode, if internal exposed _ variable in <script setup>, and worked with $refs will report Uncaught TypeError: Cannot read property '__isScriptSetup' of undefined, but worked fine in prod mode. The reproduction link:https://github.com/ygj6/bug-report-ctx.git

1. npm install / yarn
2. npm run dev / yarn dev
3. click the 'button'
4. console Uncaught TypeError: Cannot read property '__isScriptSetup' of undefined

<script setup>
import { ref } from 'vue'

const msg = ref('Hello World!')
const _ = ref(0)
</script>

<template>
  <h1>{{ msg }}</h1>
  <input v-model="msg" ref="input">
  <!-- in dev mode will report 'Uncaught TypeError: Cannot read property '__isScriptSetup' of undefined',work fine in prod mode -->
  <button @click="$refs.input.focus()">
    Focus $refs.input
  </button>
</template>

@ygj6 's PR should fix usage of _ during dev mode, and I can't reproduce the original issue. Make sure to upgrade to latest version of Vue when it's released!

Thanks so much! I just confirmed that @ygj6's bug report is more up to date than mine and seems to be the same thing - I reproduced his issue importing lodash rather than using a ref named _.

(I'm still using a slightly older version of vue 3 due to volar + typescript not quite being up to date with the latest and greatest, last time I tried to update anyway...)