Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
urbanists.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
We're a server for people who like bikes, transit, and walkable cities. Let's get to know each other!

Administered by:

Server stats:

560
active users

urbanists.social: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#lsp

1 post1 participant0 posts today
Continued thread
Public
Aral Balkan

So it does look like the TypeScript language server has a limit of 4MB source size where it disables type checking (and actually shows an erroneous error stating that exports that exist in the file do not exist) for files that are imported but not open in the current workspace/session.

Still not sure if this is documented anywhere or not (haven’t been able to find it, if it is).

99.99999% of the time, unless you’re doing niche stuff like I am, you won’t run into this.

Workaround: should you have such a large file, e.g., with a large generated object, try and refactor to split it up into multiple files and rejoin it a separate file. The actual object size/memory usage isn’t the issue, it’s the file size.

github.com/typescript-language

GitHubServer fails on import when exported object constant has too many entries/is too large · Issue #951 · typescript-language-server/typescript-language-serverBy aral
#TypeScript#max#lines
Public *
Aral Balkan

Hit an interesting limit in the TypeScript language server¹:

Looks like there’s a limit on the number of entries an object (constant) can have before the language server balks. Seems to hit it around 1,343.

(I’m generating an object for an icon library.)

Doesn’t appear to be related to file/memory size (breaking up the same number of entries into several objects works).

Anyone know what limitation exactly I’m hitting (if it’s documented somewhere?) Been searching but couldn’t find any reference to it.

¹ It’s definitely a language server limit as I tried in VSCode as well to rule out it being a limit in Helix Editor.

#TypeScript#limit#constant
Public
Benny Powers 🇮🇱🦁

#neovim 0.11 (released this week) introduces some nice convenience features for #lsp users - you can drop an LSP config into ~/.config/nvim/lsp/*.lua and if you call vim.lsp.enable with a table of LSP names, neovim will pick up your configs on startup.

What this means is that we can get rid of nvim-lspconfig and mason-lspconfig, simplifying and rationalizing config significantly

Replied in thread
Public
data0

@hyde I've been using it for an hour and couldn't find any problems. As I understand it, the #LSP changes only provide additional interfaces and don't breaking existing ones. They are not aimed at making nvim-lspconfig obsolete either. It's just some plumbing moved to core, so that nvim-lspconfig can really be just about config. Which makes a lot of sense, because while it's gotten easier to manually set up LSPs in v0.11, it still a good idea to pool configs in a plugin. #neovim

Replied in thread
Public
Fred

@bobidle Also aktiv, meinst du, und nicht nur mit einem automatisiert verschickten Crashdump und einer Zeile Fehlerbeschreibung dazu?

Mmh, zuletzt wäre das dann vermutlich mein MR vor 8 Monaten für #KDE #Kate, um den #Typst #LSP hinzuzufügen. (Ist das echt schon so lange her? Uff, vielleicht sollte ich mal prüfen, ob der überhaupt noch funktioniert und sich nicht in der Zwischenzeit etwas grundlegendes geändert hat.)

Public
Paul Buetow

I would love to do more #Perl and #RakuLang coding. Have done some Perl over the last couple of weeks again. But what brings me back to #Ruby most of the time is the better #LSP support for my Editor. E.g. renaming variables, code-actions, etc. That's just a superior experience :-( #PerlNavigator and #perltidy are OK, but not perfect.

Will soon publish a new blog post about "Perl new features" and how I used them.

ExploreLive feeds
About