-
-
Notifications
You must be signed in to change notification settings - Fork 32
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support SFC script with setup #41
support SFC script with setup #41
Conversation
Thanks for the PR, I'll try to have a look at this soon, can't make any promises though. |
Could you also add a test for |
I tested this PR, and it had a bug. I had a component imported in my script setup block, and had used it in my template. But it was removed when I ran prettier. |
@Shayan-To Can you provide your Vue file? Then we could add the content as a test case. |
@Shinigami92 Hi, I added a simple testcase including ts
@Shayan-To Do you use an component import plugin in your build setup? We are using vite and "unplugin-vue-components". I think vue-cli setups often have similar mechanisms. (https://www.npmjs.com/package/vue-cli-plugin-import-components). With such a plugin the components you use in your template don't have to be imported in your script. As I understand, this is a general limitation of 'prettier-plugin-organize-imports' because it orderes the imports of the code isolated in the specifict script tag. So there are no informations involved about the components you might use in your template. Therefore they will be removed as unused imports. So it only works together with an import component plugin. ( see also #37 ) |
I don't like to use VSCode's organize imports command does the job correctly, and it seems to work for specific script tags (you have to place your cursor inside the script tag, and it only organizes the imports of that specific script tag). All the data is inside the vue file, the problem is that this PR does not take the usages in the template into account. If I want to provide an example of an import that should not be removed:
|
I ran this PR against my repo again, and I was reminded that there can be other things that are only used in the template, and will be removed when organizing imports using this PR. Example:
|
I think those are very valid concerns about how this library handles components and other imports used only in the template. The use case you describe won't work with plain script tags either: |
I would love to have this merged, just a progress, step by step |
Superseded by #56. |
This should be backward compatible and support <script setup> Tags as well.
Not 100% sure about using both tags in one file (with and without setup) but I think this would be an edge case.