Open dead-claudia opened 5 years ago
Hi. You mentioned it's an unsaved file. Atom can't infer where the relative path is from the file as it's still in memory and not in an exact location.
What should be considered is a safe way for it to have its exception caught.
I get that. It still should at least tolerate an in-memory file, though.
IMHO, I feel it should just not attempt to resolve non-native modules (or at least non-global modules) if it hasn't been saved yet. fs
is okay, but it shouldn't offer completions for ../lib/foo
, for example. You could go either way with something like lodash
, however.
yes. I agree. Will need to manage that.
On Tue., 13 Nov. 2018, 11:11 am Isiah Meadows, notifications@github.com wrote:
I get that. It still should at least tolerate an in-memory file, though.
IMHO, I feel it should just not attempt to resolve non-native modules (or at least non-global modules) if it hasn't been saved yet. fs is okay, but it shouldn't offer completions for ../lib/foo, for example. You could go either way with something like lodash, however.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/nkt/atom-autocomplete-modules/issues/125#issuecomment-438088955, or mute the thread https://github.com/notifications/unsubscribe-auth/AKXAhrzuIn2j1LlLC4ZKc_iGglvFOgmiks5uuhqzgaJpZM4YZOfm .
[Enter steps to reproduce:]
const foo = require("../mod")
foo
to{bar}
Atom: 1.32.2 x64 Electron: 2.0.9 OS: Mac OS X 10.13.6 Thrown From: autocomplete-modules package 2.2.5
Stack Trace
Uncaught TypeError: Cannot read property 'substring' of undefined
Commands
Non-Core Packages