-
-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
@vue/shared generateCodeFrame can infinite loop, breaking a build process. #3987
Comments
The loop indeed does increment I just freshly pulled the repository, ran |
I'm not sure what more information I can provide given that the repo does break for me. |
make sure you update the dependencies then. I used yarn to install them |
Cleared my Here is the generated |
...I bet this has to do with the way the parser is consuming characters and adjusting |
Yeah, so the problem here is: Basically, everything else in the parser deals with If there are enough lines in the file proceeding the piece of code that the |
Version
3.1.1
Reproduction link
https://github.com/DV8FromTheWorld/vue3-sfc-compiler-bug-repro-template
Steps to reproduce
npm install
it.npm run serve
BrokenComponent.vue
file.What is expected?
The build should complete and generate warnings about using undecorated
<template>
elements in Vue3.What is actually happening?
The build hangs forever due to an infinite loop when generating the code frame to display with the vue-migration compatibility warning.
I originally encountered this problem when transitioning my application from Vue 2.6 to
@vue/compat: 3.1.1
. The problem surfaced as a Webpack build that would never complete the compilation step. The Vue-loader would successfully separate the SFC into the specific template/script/style portions and pitch them, but when compiling the template (thus generating migration warnings) the system will get stuck.In the screenshot below observe that the
generateCodeFrame
will infinite loop.This will infinite loop because
j >= lines.length
will resolve to true and hit thecontinue
statement without incrementingcount
any further.It is possible that the culprit causing this problem is not so much the
generateCodeFrame
function itself but instead the function calculating theloc
for the start and end of the<template> ... </template>
. From my testing, theloc.*.column
andloc.*.line
for bothloc.start
andloc.end
were accurate, however theloc.*.offset
for both seemed to be off by 75 - 110 characters. ThegenerateCodeFrame
code usesoffset
as it's source of truth here and thus could be the problem here.Additionally, another issue caused by this oddity with the
offset
is that the code frame actually generated has the^^^^^^^
pointers multiple times in a very confusing fashion. This is caused by thecount
not exceedingend
fast enough.The text was updated successfully, but these errors were encountered: