core-ai-bot
commented
3 years ago 
Hi Erik@eztierney - not sure if this is truly a JS Code Hint issue, please feel free to reassign as you find out more.
Thanks,
Peter :)
Open core-ai-bot opened 3 years ago
core-ai-bot
commented
3 years ago
Hi Erik@eztierney - not sure if this is truly a JS Code Hint issue, please feel free to reassign as you find out more.
Thanks,
Peter :)
core-ai-bot
commented
3 years ago core-ai-bot
commented
3 years ago 
@eztierney - wondering if you've had a chance to look at this and figure out whether it's important to take for this sprint - we're trying to be pencils down today. It's ok to punt if this is an edge case. Thanks!
core-ai-bot
commented
3 years ago 
@njx I think this is just a side effect of how we look for files. Maybe there is a better way to implement this, but I don't think it's causing any problems.
When tern sees a call to require it asks us to resolve the file. Since we don't know what the baseUrl is, we look for the file in the following places:
For 1 & 2 we call DocumentManager.getDocumentForPath(), which calls FileUtils.readAsText(). We chain these lookups by using the .fail() of the promise returned from getDocumentForPath() - maybe theres a better way to decide if a file exists or not that we should be using instead?
core-ai-bot
commented
3 years ago
Ah, that makes sense. I think a slightly more direct way to get this info is to create a NativeFileSystem.FileEntry for the file and then call getMetadata on it (which under the hood basically does a stat()). I don't know if there would be a significant performance difference between the two though.
In any case, I think that makes this a low pri bug. Punting out of the sprint.@redmunds let us know if you disagree.
(It would be interesting to consider having a way for the user to specify what their require baseURL is on a per-project basis. Feature request :))
core-ai-bot
commented
3 years ago 
I don't think this is important for this sprint. I'm not sure about other projects, but for Brackets the most likely place is 2, so maybe swapping the order of 1 & 2 would be a little more efficient?
core-ai-bot
commented
3 years ago
It depends on if you're editing core brackets, or one of the extensions. For extensions 1 is usually what you want - we may have been biased towards extensions when we implemented this in our extension ;)
@njx Now that darrell has implemented a preferences file, it should be relatively easy to implement a baseURL option.
core-ai-bot
commented
3 years ago 
Maybe I don't understand what's going on, but it appears that JavaScriptCodeHints are looking for Brackets modules in the wrong place.
Recipe:
Results: You'll see entries for
readAsText()trying to read Brackets modules inside current project.I copied data from my project below. Project path: /Users/randyedmunds/Sites/brackets
And they are also attempting to read from the sub-folder where the open files are: /Users/randyedmunds/Sites/brackets/scratch
The code should be able to find Brackets modules in either of these folders: Development machine: [app-folder]/Contents/dev/src Installed build: [app-folder]/Contents/www/src