Open core-ai-bot opened 3 years ago
Comment by pthiess
Monday May 13, 2013 at 18:33 GMT
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 :)
Comment by njx
Friday Jun 07, 2013 at 18:56 GMT
@
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!
Comment by eztierney
Friday Jun 07, 2013 at 19:19 GMT
@
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?
Comment by njx
Friday Jun 07, 2013 at 19:25 GMT
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 :))
Comment by redmunds
Friday Jun 07, 2013 at 19:32 GMT
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?
Comment by eztierney
Friday Jun 07, 2013 at 19:47 GMT
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.
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