Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ryan
    @RyanSquared
    right so
    Jesse Atkinson
    @jsatk
    My vimrc is pretty robust but very very few flow or ALE related things in it. https://github.com/jsatk/dotfiles/blob/master/tag-vim/vimrc#L313-L339
    Ryan
    @RyanSquared
    it looks like the flow-language-server linter uses flow lsp
    Jesse Atkinson
    @jsatk
    omg
    well isn't this confusing.
    Ryan
    @RyanSquared
    so it's not that the flow-language-server itself is deprecated, it's that it's no longer using a deprecated interface
    yeah it's unfortunate
    but just making the normal flow linter an LSP linter breaks people who are using older interfaces
    Jesse Atkinson
    @jsatk
    so in order for me to get :ALEHover working again i should enable both flow and flow-language-server in my list of linters?
    Ryan
    @RyanSquared
    you don't need flow, you should only need flow-language-server
    actually it looks like flow-language-server has used the flow command straight from the beginning of it's history: https://github.com/w0rp/ale/commit/eda3878a6c121d94f83726ac5ebd059ee0d859ef#diff-f5c789fd83102cd871bb27131cc70bbb
    so I'm not quite sure how it worked in the first place unless you only recently disabled it.
    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.