Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jesse Atkinson
    @jsatk
    OMG it's back.
    RyanSquared: thank you so much. I am overjoyed.
    Ryan
    @RyanSquared
    \:D/
    i'll go comment on the issue & close it
    Jesse Atkinson
    @jsatk
    would you like me to update the ticket?
    okay. thank you Ryan. You're very kind.
    Also i just realized i linked to one of the wrong links in that thread but :shrug: we figured it out. ty.
    Harry Felton
    @hbomb79_gitlab

    Hey, thought I should come here before making an issue because I'm probably missing something..

    I've been writing a node project for some time now, and I decided to switch to Typescript. I've been using ALE for a while so I'm pretty certain it's not broken but I think I might be missing some crucial configuration.

    The problem is that ALE constantly tells me Cannot find module X, whether it's fs, rxjs, or a local file in the projects source tree. If I use tsc, this error does not show up and the files compile fine. I'm really quite confused as to why one linter tells me one thing, and the other.. something else.

    From what I can tell, ALE is using tsserver, but I don't know how to check because :ALEInfo just gives me a list and :ALEDetail doesn't indicate which linter it got the error from. I suspect whatever linter is being used isn't respecting my tsconfig.json file.. but I'm really just thinking out loud here, I've got no evidence to suggest it's not, other than the above which may be indicative of a completely different issue.

    If anyone here has any ideas, I'd really appreciate it. I'm starting to pull my hair out over here.

    May be worth nothing I installed typescript-vim however the compiler that comes with that script is set to tsc, so I doubt that's the linter throwing the error as when I run tsc manually it has no problems.
    Harry Felton
    @hbomb79_gitlab
    I've disabled the typescript-vim package and manually set the filetype as typescript; the issue still remains, which to me indicates it's either something I haven't configured with ALE, or a bug with ALE or the underlying linter. Trying everything I can think of
    Harry Felton
    @hbomb79_gitlab
    I'm monitoring the tsserver output. When I save a file in Vim it spits out a bunch of information; no where in there is an error regarding not being able to find a module... I'm stumped. tsserver is being used, but clearly ALE is using the output of another linter.
    Harry Felton
    @hbomb79_gitlab
    I set let g:ale_linters = {'typescript': []}, this stopped the error (but obviously also stopped any linting). Setting let g:ale_linters = {'typescript': ['tsserver']} saw the incorrect 'Unable to load module' errors come back, so it's absolutely using tsserver (and accoring to :ALEInfo it is the one contained locally in node_modules)... I.. ugh
    w0rp
    @w0rp
    @hbomb79_gitlab The best way to look at all of what tsserver is doing is use the ch_logfile function in Vim to log all of the channel/job data. If you're having module import problems, the problem probably lies in tsconfig.json.
    What's most likely to work is having node_modules and tsconfig.json in the same directory, and your code in subdirectories beneath that directory. You might need to use settings like "baseUrl": "." or similar for imports to work everywhere.
    I can't share the code I write at work, which is a pretty large TypeScript codebase, but I can share this free software repo I created quite recently. https://github.com/w0rp/report-alchemy
    You can test out ALE's integration with tsserver by cloning that and running yarn. npm install probably also works, but I am used to yarn now.
    Harry Felton
    @hbomb79_gitlab

    Thanks @w0rp, never knew the ch_logfile function was a thing, very helpful.

    I was thinking the same regarding the location of the tsconfig.json file relative to the node_modules directory; however having them in the same directory didn't work.

    My directory structure was

    tsconfig.json
    node_modules
    src
        bootstrap.ts
        /classes
            ...

    Even when opening the file bootstrap.ts from the root of the project (ie: vim src/bootstrap.ts) the linting still failed. However moving the tsconfig.json file in to the src directory magically fixed the problem.
    Which to me, makes very little sense as every where I've read says that tsserver looks up the directory tree until it finds one.
    My guess is it stops looking at the same directory as the last source file, so because no source files are in the root dir (probably doesn't help that I specify an include in my tsconfig.json that tells it to look in src), it doesn't look there for the config.

    IDK, probably talking out my ass.

    Either way, it works now. Thanks for your input. I'll look in to the baseUrl property too, might be a better way to specify the source than include: []

    Harry Felton
    @hbomb79_gitlab
    God knows why but after a git pull.. ALE is now reporting 'Unable to find module X' again for every. single. module. So pissed, I pretty much ONLY installed Jest. No changes to the tsconfig at all.
    Harry Felton
    @hbomb79_gitlab
    In fact, the config and directory structure is EXACTLY the same on two different machines. Works fine on one, and throws pointless errors on the other
    Harry Felton
    @hbomb79_gitlab
    On MacOS, works fine. Windows 10 running Cygwin, completely broken.
    Harry Felton
    @hbomb79_gitlab
    I compared the log output from tsserver on my Mac and Windows machine.
    Info 0    [18:7:15.843] Starting TS Server
    Info 1    [18:7:15.845] Version: 3.5.2
    Info 2    [18:7:15.845] Arguments: C:\Program Files\nodejs\node.exe C:\cygwin64\home\HarryF\ImportProcessor\node_modules\typescript\bin\tsserver
    Info 3    [18:7:15.846] Platform: win32 NodeVersion: 12 CaseSensitive: false
    Info 4    [18:7:15.849] Binding...
    Info 5    [18:7:15.854] event:
        {"seq":0,"type":"event","event":"typingsInstallerPid","body":{"pid":12684}}
    Info 6    [18:7:15.855] request:
        {"seq":null,"arguments":{"file":"/home/HarryF/ImportProcessor/src/classes/Application.ts"},"type":"request","command":"open"}
    Info 7    [18:7:15.856] Search path: /home/HarryF/ImportProcessor/src/classes
    Info 8    [18:7:15.856] ConfigFilePresence:: Current Watches: :: File: /home/HarryF/ImportProcessor/src/classes/tsconfig.json Currently impacted open files: RootsOfInferredProjects:  OtherOpenFiles: /home/HarryF/ImportProcessor/src/classes/Application.ts Status: File added to open files impacted by this config file
    ...
    Info 20   [18:7:15.858] For info: /home/HarryF/ImportProcessor/src/classes/Application.ts :: No config files found.
    No config files found huh... weird because there is DEFINITELY one present, and it checked that location
    Info 12 [18:7:15.857] ConfigFilePresence:: Current Watches: :: File: /home/HarryF/ImportProcessor/tsconfig.json Currently impacted open files: RootsOfInferredProjects: OtherOpenFiles: /home/HarryF/ImportProcessor/src/classes/Application.ts Status: File added to open files impacted by this config file
    On my Mac machine, the log looks pretty similar except instead of No config files found, it actually comes back with the correct path and all is well
    Jesse Atkinson
    @jsatk
    Sometimes the gutter for ALE continues to show errors however there are no errors and when I move my cursor to those lines or run ALELint there are no errors reported. Is there a way to 1. Prevent this or 2. Force the gutter to re-draw?
    w0rp
    @w0rp
    If that's a bug, report it on GitHub.
    w0rp
    @w0rp
    Now ALE is under a GitHub Organization so more people can contribute by managing issues. :+1:
    w0rp
    @w0rp
    I still haven't fixed my home server and I'm too busy/lazy to set up IRC on my laptop. I'll sort it out eventually.
    Christian Maniewski
    @chmanie
    Is it somehow possible to debug the commands that ale is running somehow? I have a problem where just in a particular project the fixing doesn't work for typescript while the linting itself works
    Christian Maniewski
    @chmanie
    Never mind. I had a faulty version of eslint installed
    A Man Of Science
    @jad-b
    Hi :wave: - I've been struggling to use a linter executable that's "wrapped" by another executable. Doing so allows the executable to be re-used across multiple projects. In my case, the linter is "hlint", the wrapper is stack. stack exec hlint [file] works from the CLI, but setting let b:ale_haskell_hlint_executable = "'stack exec -- hlint'" errors with: (executable check - failure) 'stack exec hlint'. Any ideas about how to do this?
    w0rp
    @w0rp
    You could try setting the _executable to 'stack', and the _options to 'exec -- htlint'. I can't guarantee that will work forever, but it will probably work for now.
    @chmanie For future reference, you can see what ALE is running by using :ALEInfo.
    A Man Of Science
    @jad-b
    @w0rp Thanks for the suggestion - I managed to get it to work, but it took one more step that I don't quite understand. By :ALEInfo, that actually ran 'stack exec hlint -- exec hlint'. Setting hlint_executable = 'stack' and hlint_options = ''actually ran (executable check - success) stack (finished - exit code 1) ['/bin/bash', '-c', '''stack'' exec ''hlint'' -- --color=never --json - < ''/tmp/nvimNImjwE/1/APISpec.hs'''], so it works, but I don't know why...Anyway, maybe you'll find that curious.
    w0rp
    @w0rp
    I remember now. That's because someone already added support for setting the executable to 'stack'. If the executable path ends in 'stack' for most of the Haskell linters, if not all of them, it will execute the linters via stack. You can see this in autoload/ale/handlers/hlint.vim.
    A Man Of Science
    @jad-b
    What a visionary. Thanks for the help!
    Christian Rapp
    @crapp
    Hi, currently ale overwrites the signs in the signcolumn of the ones youcompleteme provides. Can I somehow control this? I found something about a priority that can be used but unsure if ale supports this
    w0rp
    @w0rp
    Look at recent pull requests. There's an open pull request for that.
    Bashar Harfoush
    @basharh
    Hello, I'm not sure if this is an issue with ALE or eslint6. eslint@6 now looks for plugins using the current working directly and not the locations of the eslint.js script. I believe they did this to support loading local modules even when using a global eslint.js. The downside is that if you run eslint6 from any other location outside the project(which means PWD is not a sub-directory of the project), then eslint6 fails to find the required plugins. ALE fails in this case because it relies on absolute paths to run eslint6. For example running something like this fails which what ALE runs: /Users/bashar/work/projects/adl/adl-backend/node_modules/eslint/bin/eslint.js /Users/bashar/work/projects/adl/adl-backend/src/app.ts if PWD is /Users/bashar/. Is there a way we can set the PWD explicitly when running eslin6?
    Bashar Harfoush
    @basharh
    I reached out about this issue in https://gitter.im/eslint/eslint. It seems there might be a workaround but a better solution might be to set CWD in the job options in ALE to the buffer or linter directory.
    cxgslegend
    @cxgslegend
    Hey guys, I am trying to get rls to work with my setup. I have never used ale before, so forgive me if I am doing something obviously wrong. But nothing is happening visually when I put an obvious error in my rust file. When I run ALEInfo it gives me Available Linters: ['cargo', 'rls', 'rustc'] Enabled Linters: ['rls']. Also it gives me (executable check - success) rls (started) ['/bin/zsh', '-c', '''rls''']. And I can use ale-go-to-definition. So am I missing something? Shouldn't it be putting errors in the gutter?
    cxgslegend
    @cxgslegend
    Okay, so I figured out the answer to my last question. But I have a new one. I really don't like the autocomplete preview window that opens. I have info in dropdown. So how can I get rid of the preview window? Thanks
    w0rp
    @w0rp
    @cxgslegend You can disable the preview window by changing your completion options in Vim.
    See :help completeopt. If you don't have preview in your setting there, ALE won't show the preview window.
    cxgslegend
    @cxgslegend
    Thank you @w0rp. But if I turn off preview in the completeopt, then ale_detail wont work anymore. It would be nice to be able to have a keybinding for ale_detail, so I can use it when I need to, but still get ride of the live preview while typing.
    w0rp
    @w0rp
    The preview window for completion is separate from the preview window usage for :ALEDetail, so that shouldn't be an issue.
    cxgslegend
    @cxgslegend
    You are right, I was doing something dumb again. Thanks @w0rp!
    physkets
    @physkets
    Hi! According to the following gcc doc:
    https://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-Options.html
    The options should include a '-cpp' preprocessor flag for certain file extensions.
    Is there any way to add that?
    Jesse Atkinson
    @jsatk
    Hm. I'm having trouble getting Typescript working with Ale out of the box. I looked at the docs but didn't see anything diving into it. The main features I want to use are :ALEHover and :ALEGoToDefinition. Any help/tips getting Typescript support in ALE?
    Christian Maniewski
    @chmanie

    @jsatk hmm, it does work for me. I have an ftplugin file set up for typescript:

    let b:ale_fixers = {'typescript': ['prettier', 'eslint']}

    Also I think TS should be installed in your project and you will need a tsconfig.json