You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note this is not full .eslintrc file, but just relevant part with the configured rule in question
What did you do?
No code here because this issue can be reproduced with both valid and invalid code.
What did you expect to happen?
Memory consumption does not significantly change when no-unsupported-features rule is enabled.
What actually happened?
ESLint output is not relevant here, as we need to look into "Activity Monitor" instead.
With the rule enabled, during the lint process (which we run as eslint --ext .js,.vue .) RAM consumption keeps raising and peaks at to 3.5G-4Gb level. When I disable the rule – it doesn't go more than 800-900Mb. I tried to disable other rules, but it seems this is the one which causes the issue.
I tried to debug it myself and I narrowed it down to this line:
This file is used in the style-css-vars-injection syntax spec, which is part of the no-unsupported-features rule.
From my understanding, this cache is created globally per entire lint process, while it would be populated with values from each of the scanned files. This cache uses VElement objects as a key, which makes them "trapped" in this cache for the duration of the entire lint process. As a result Node.js cannot garbage collect those references when scan for individual file is done.
Simple change to WeakMap seems to be solving the problem:
Btw during my experiments, I noticed that part of that code that reads from the cache is never executed. I'm not sure what is the use case for this cache implementation, but for now it seems redundant for me and it could be removed altogether.
Repository to reproduce this issue
I'm not sure if you still need it, but I can add it if you confirm.
The text was updated successfully, but these errors were encountered:
@ota-meshi That another rule with memory leak is no-unused-properties, but it seems the cause is exactly the same – it also uses style-variables utility. So the fix you did already should be enough. Thanks again.
Uh oh!
There was an error while loading. Please reload this page.
Checklist
Tell us about your environment
Some additional details:
*.vue
files and around 2000 of*.js
files with// @vue/component
commentPlease show your full configuration:
Note this is not full
.eslintrc
file, but just relevant part with the configured rule in questionWhat did you do?
No code here because this issue can be reproduced with both valid and invalid code.
What did you expect to happen?
Memory consumption does not significantly change when
no-unsupported-features
rule is enabled.What actually happened?
ESLint output is not relevant here, as we need to look into "Activity Monitor" instead.
With the rule enabled, during the lint process (which we run as
eslint --ext .js,.vue .
) RAM consumption keeps raising and peaks at to 3.5G-4Gb level. When I disable the rule – it doesn't go more than 800-900Mb. I tried to disable other rules, but it seems this is the one which causes the issue.I tried to debug it myself and I narrowed it down to this line:
This file is used in the
style-css-vars-injection
syntax spec, which is part of theno-unsupported-features
rule.From my understanding, this
cache
is created globally per entire lint process, while it would be populated with values from each of the scanned files. This cache usesVElement
objects as a key, which makes them "trapped" in this cache for the duration of the entire lint process. As a result Node.js cannot garbage collect those references when scan for individual file is done.Simple change to
WeakMap
seems to be solving the problem:Btw during my experiments, I noticed that part of that code that reads from the
cache
is never executed. I'm not sure what is the use case for this cache implementation, but for now it seems redundant for me and it could be removed altogether.Repository to reproduce this issue
I'm not sure if you still need it, but I can add it if you confirm.
The text was updated successfully, but these errors were encountered: