Reload npm link/symlink dependencies when they change

[andreialecu]

This is not a big deal, since it seems to work with the ctrl+' shortcut as a workaround.

The problem is that when you have a secondary project/library npm linked to the main project, and you make a change to it, the main project won't see the changes until a full refresh is forced.

I'm not sure if it would be possible to set up a watch on the imports and do this automatically.

webpack seem to be able to detect such changes and trigger rebuilds immediately in watch mode, so I believe there could be a solution.

[laurelnaiad]

Interesting find. I had noticed that more and more I am needing to reload the window to pick up changes. I guess your finding suggests that it's because I started relying on moduleResolution: 'node' and npm link. I wonder if there's an assumption in its implementation that such modules are a bit more "static/stable" than others (i.e. considered not really part of the project somewhere in the strategy).

(edit: of course, it could also be that theres's just some code in the refresh cycle that's not following symlinks regardless of the module resolution strategy)

[basarat]

Actually we don't do any file system watching. If a file changes i.e. gets edited in atom we know ... otherwise we don't. Sync is a convenient shortcut for you to go crazy with the file system 🌹

More : https://github.com/TypeStrong/atom-typescript/blob/master/docs/faq.md#atom-typescript-is-complaining-about-not-finding-files-or-other-weird-errors

Don't let my closing the issue stop you from discussing further 🌹

[laurelnaiad]

@basarat I think you closed this prematurely without understanding the problem.

This happens when files are modified in atom-typescript (at least to me it does), and is specific to those that are in context of a tsconfig following a path that is under an npm linked directory under node_modules. This isn't about modifying the files from some other tool or process. Please consider reopening.

[andreialecu]

I can confirm what @laurelnaiad is saying.

[laurelnaiad]

the more I think about it, I'm guessing that this is due to two or more tsconfig files all matching a single file. I'm building a "common" project that is referenced by two other projects, and so references are to the same files in multiple places. Is atom-typescript errantly assuming that a file belongs to only one project?

[basarat]

This isn't about modifying the files from some other tool or process. Please consider reopening.

Done 🌹

If one does a modification from the tree view though there is no way for us to know. See this issue : atom/tree-view#433 Hence I said "edit a file".

Is atom-typescript errantly assuming that a file belongs to only one project?

Yes. The alternative would be to allow the user to select an active project (which doesn't exist at the moment).

@laurelnaiad I've been fairly MIA in maintaining this (beyond the usual update to typescript latest and ensuring there isn't a regression. Personally busy with http://alm.tools). If you want I can add you as an owner here 🌹

PS: If there isn't an actionable item or its too complex feel free to ping me to close it again 🌹

[laurelnaiad]

The alternative would be to allow the user to select an active project

Hmm.. if a map of what's in the tile files array of each tsconfig file in the tree were kept in memory, could not this map be consulted to determine which project or project is referencing any given file? Such a map would be authoritative across the window, right? I gather that the package is mostly inactive when a .ts file isn't in focus... maybe that's why you're working from the .ts file outward?

Seriously though, @basarat -- while I humbly thank you for offering to add me :) -- it's not like I have lots of time, either! I seem to have just enough time to raise a little noise here and there. I can't promise to be very contributory very regularly. 🎢 <-- she made a roller coaster symbolizing her schedule

[basarat]

If a map of what's in the tile files array of each tsconfig file in the tree were kept in memory, could not this map be consulted to determine which project or project is referencing any given file

There is such a map (here:

atom-typescript/lib/main/lang/projectCache.ts

Line 48 in f50fe08

var projectByFilePath: { [filePath: string]: Project } = {}

) but its just file -> project and not file -> projects As soon as one does file -> projects a bunch of deduping 🐛 scenarios open (inline errors, autocomplete).

A friend did that once : https://github.com/TypeStrong/tspms and its a bunch of code.

I imagine a project selector : https://github.com/alm-tools/alm/tree/master/docs/features#project-search is a simpler experience to maintain and explain 🌹

PS: I completely under about the schedule

[github-actions]

This issue has been marked as stale because it did not have any activity for the last 90 days or more. Remove the stale label or comment or this will be closed in 14 days