-
Notifications
You must be signed in to change notification settings - Fork 202
File globbing slow with large node_modules folder #332
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
Comments
Seems Microsoft is also trying to do something similar: microsoft/TypeScript#3043 |
can you try putting the exclude first:
|
Tried these (note: we need the .d.ts line too, as we generate the .js etc next to the .ts in this project):
They are all still slow, and worse, they add .ts below node_modules files to the list. Also tried
just to see if it was our last .d.ts line, but that still leads to stuff in node_modules to be included (and it's also slow). |
Out of curiosity, could you just do '!./node_modules' or '!./node_modules/' ? I don't think there's any reason to drag the files inside node_modules into it... |
I'm not at my work PC right now, but I think I tried that too and that it didn't work. It was a bit cumbersome to test though, given that I typically had to wait a long time and often needed to kill Atom, so I may have overlooked something. There also seems to be a difference between starting with 'nothing', a slash, or './', and I can't remember whether I tried them all. I simply moved the tsconfig a subdirectory for now... |
Note: Workaround move tsconfig to some sub directory e.g. |
The workaround works for me. Thanks |
AFAIK tsconfig.json does not support globes. When you're talking about adding or removing globs from tsconfig.json where is that config file exactly? |
we're not adding / removing globs ... we are adding / removing files in the file system and maintaining that in the |
You mean The thing is, even though moving tsconfig.json to src directory works but I prefer it to be on the root of my project. The structure of my project is like:
Even though I add |
Even the workaround only works for the small projects. Now my project has 40+ ts/tsx files and 20+ d.ts files. Now it's very slow. |
Shouldn't be the case. We have 300+ files and it works fine. |
Also running into this issue. Was comparing my TS experience between Atom and VSC and it's pretty much unusable in Atom at the moment. As everyone says, I try to get autocomplete on something and it'll queue up requests for The
|
I am also facing the same issue as @intellix (in a project generated by angular-cli). The number of pending requests keep on increasing with every keystroke. It will be great if this gets resolved soon. |
@intellix any luck fixing this issue with |
@tttee try adding
to |
@ghpabs Thank you, that works very very well. I don't know what For comparison with Edit: If someone else stumbled upon this issue and wants to know what
|
@ghpabs Adding that to my tsconfig does not seem to solve the issue. Pending request still increasing each keystroke. |
ok so I just looked a little more into this. I see that defining a "filesGlob" as suggested above fixes it and gets it working again. angular-cli generates a project with tsconfig.json containing only a "files" option, like so: "files": [
"main.ts",
"typings.d.ts"
] This issue is about this happening if you have a large node_modules folder and so I tried adding this to rectify that: "exclude": [
"node_modules"
] This doesn't solve the problem. It seems the issue is that Atom-Typescript doesn't work at all unless you have a |
Also, angular-cli places the tsconfig in src/ which should also exclude node_modules. I suppose adding support for the files array would mitigate this issue entirely, and make atom-typescript more compatible with other editors |
After some digging around, I think the issue is when trying to edit something which is not exported (directly or re-exported) in a file that exists in the files array in tsconfig.json. If atom-typescript can find the file with filesGlob and add it, everything is fine, but removing filesGlob and editing a file which doesn't exist in the files array already will make it really slow. Only including main.ts and referencing everything from there doesn't work very well. |
Try to run Atom in administrator mode. |
That's not really a solution though. I've decided to take a further look at how this could be resolved in a couple of weeks, when I have more time. The issue doesn't seem to be trivial. |
try add ur
go to terminal rebuild ur |
Just a thought, but with TypeScript 2.0 coming soon, maybe "filesGlob" and calculating the "files" property should be deprecated. So if your tsconfig.json has "include", Atom-Typescript goes into TypeScript 2.0 mode Would this be an easier/better solution? I'm using TypeScript 2.0.2 and atom-typescript 10.1.6 tsconfig.json "include": [
"app/assets/**/*.ts"
],
"exclude": [
"node_modules",
"target"
],
"filesGlob" : [
"app/assets/**/*.ts",
"!node_modules/**",
"!target/**",
] Note: paths are weird because I'm working on a Play project. |
Trying out the different solutions provided here has yielded a few interesting results. When I add the If I remove the changes to |
Atom Typescript adds the following
filesGlob
totsconfig.json
by default:This indeed excludes things from
node_modules
, but it apparently still causes the fullnode_modules
folder to be traversed.I've tried replacing the second line with
"./node_modules/**"
and"./node_modules/"
in order to prevent it from entering the directory at all, but that didn't seem to help (or didn't work at all).We have a very large number of node modules in this particular tree, which makes Atom very slow for many operations (adding a file, renaming) and causes frequent hickups while editting. Haven't timed it exactly, but it's in the order of tens of seconds before e.g. a save of tsconfig.json 'notices' added or removed files.
As an experiment, I moved the
tsconfig.json
to the subdir that actually contains the TS code (which doesn't have a node_modules dir), and now saving tsconfig,json is 'just' a second or two (it's a fairly large codebase).Somewhat related to #217, which also got slow due to traversing large number of directories.
Is there e.g. a different glob pattern that may help?
The text was updated successfully, but these errors were encountered: