semantic-source
typescript-language-server
Our great sponsors
semantic-source | typescript-language-server | |
---|---|---|
23 | 49 | |
8,706 | 1,472 | |
0.0% | 6.0% | |
0.0 | 8.3 | |
about 1 year ago | 2 days ago | |
Haskell | TypeScript | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
semantic-source
-
The Meaning of Monad in MonadTrans
One production example I know: GitHub code navigation is written in Haskell https://github.com/github/semantic
-
How to Get Started with Tree-Sitter
ah, easy. it's because support has not been added into https://github.com/github/semantic which is the tech that powers the GitHub UI. Adding support is pretty easy/mainly glue code [1] that imports the tree sitter API.
[1] https://github.com/github/semantic/blob/793a876ae45d38a6bd17...
I believe they use semantic (Haskell program that uses tree-sitter) for navigation: https://github.com/github/semantic
So the answer may be that semantic does not yet have support for the language in question.
- Scala community now has control over the official Scala grammar for tree-sitter 🎉
- 2022 State of Haskell Survey
-
11 Companies That Use Haskell in Production
GitHub used Haskell for implementing Semantic, a command-line tool for parsing, analyzing, and comparing source code.
-
What happened with GitHub's semantic project?
As far as engineering effort, you can read this GitHub comment for an overview of where we’d like to take the project in the future. The tl;dr here is that the open sum type view of the world made it very concise to fold over syntax trees (since such a view of data is ultimately unityped, recursion schemes Just Work), but the tradeoff thus associated—namely, that you have to parse a concrete syntax tree into an open-sum view (a complicated and painful-to-read process), that you can never really be sure how a given syntax tree is shaped, and that the types don’t help you nearly as much as they could—proved to be too onerous to deal with. Going forward, we’re generating syntax types from the AST once per target language, and working on an abstraction (probably via this generated code; I made five separate efforts at using Generics for this, and failed every time) that recovers at least some of the convenience of recursion schemes. It turns out that recursion schemes over a mutually recursive syntax tree—as pretty much every language’s syntax trees are, in practice—are pretty much an unsolved problem, especially when extended to languages like TypeScript, which have hundreds of different syntax nodes.
I'm just curious. It seems there hasn't been much activity in https://github.com/github/semantic Is GitHub still using semantic it to power some code navigation features? Has it been abandoned or is there some successor project that has taken its place? Is there any writeup / lessons learned about this project?
-
Stack Graphs
is this from Github semantic (https://github.com/github/semantic)?
Seems very suspicious since it’s the same goal using the same technologies. The latest commit is 4mo ago but i assume they have a closed-source version they’ve been working on.
Meanwhile their Tree-Sitter-based semantic parser[1] looks abandoned. There is even rotting for years pull request[2] adding support of the same stack graphs into it.
typescript-language-server
-
Let's write an Emacs treesitter major mode
That was interesting, thanks for pointing it out
I was tremendously sad to see that the Typescript Language Server wasn't owned by Microsoft <https://microsoft.github.io/language-server-protocol/impleme...>, since if there was any sanity in the world a spec bump would travel with a reference implementation showing how they envision such a thing being used
But, I found that the Typescript Language Server that they did list does indeed have a semantic-tokens module in it, although it's much shorter than I would have expected from reading that section in the spec: https://github.com/typescript-language-server/typescript-lan...
-
Formatting on save not working
[[language]] name = "python" roots = ["pyproject.toml"] formatter = { command = "black", args = ["--quiet", "-"] } language-server = { command = "pyright-langserver", args = ["--stdio"] } config = {} auto-format = true [[language]] name = "rust" auto-format = true # [[language]] # name = "typescript" # auto-format = true # formatter = { command = "prettier", args = ["--parser", "typescript"]} # # pass format options according to https://github.com/typescript-language-server/typescript-language-server#workspacedidchangeconfiguration omitting the "[language].format." prefix. # config = { format = { "semicolons" = "insert", "insertSpaceBeforeFunctionParenthesis" = true } } [[language]] name = "tsx" formatter = { command = 'prettier', args = ["--parser", "typescript"] } auto-format = true [[language]] name = "javascript" auto-format = true formatter = { command = 'npx', args = ["prettier", "--config", ".prettierrc", "--parser", "javascript"] } # formatter = { command = "prettier", args = ["--parser", "javascript"]} [[language]] name = "css" formatter = { command = 'prettier', args = ["--parser", "css"] } [[language]] name = "markdown" # https://github.com/executablebooks/mdformat formatter = { command = "mdformat", args = ["-"] } [[language]] name = "json" formatter = { command = "prettier", args = ["--parser", "json"] } [[language]] name = "toml" auto-format = true # https://github.com/bd82/toml-tools/tree/master/packages/prettier-plugin-toml formatter = { command = "prettier", args = ["--parser", "toml"] } [[language]] name = "yaml" indent = { tab-width = 2, unit = " " } formatter = { command = "prettier", args = ["--parser", "yaml"] } [[language]] name = "astro" scope = "source.astro" injection-regex = "astro" file-types = ["astro"] roots = ["package.json", "astro.config.mjs"] language-server = { command = "astro-ls", args = ["--stdio"] } config = { "typescript" = { serverPath = "/Users/matteostara/.nvm/versions/node/v18.16.0/bin/typescript-language-server" }, "environment" = "node" }
-
Struggling with javascript completion with LSP
Crossposting from github, because the response rate there has been pretty slow: https://github.com/typescript-language-server/typescript-language-server/discussions/730
Depending on the language server version, you may be running into https://github.com/typescript-language-server/typescript-language-server/issues/631. I temporarily fixed it for me by simply sticking with an old enough server build, though judging by the latest typescript-language-server commits a very recent build from master should also work
-
There's another typescript LSP that wraps the official VSCode typescript extension and has almost the same features - vtsls
Before, I was using typescript-language-server as it is LSP compliant but it was slow and lacks the features of what VSCode's implementation has, like extracting functions, constants, types into interfaces or alias and single imports. Auto-completion was also not very predictive as sometimes it works and sometimes it doesn't. For instance, I was having trouble getting it to auto-complete common attributes like className or href in JSX projects. It could be that I may be doing something wrong but didn't find any solution on how to get it properly working.
-
What could cause my LSP to be so slow and sluggish? Takes anywhere from 1 to 8 seconds to show auto-completion results and hide/ unhide errors.
Then this is highly likely issue of typescript-language-server. You might consider opening an issue for it.
-
PSA: Configuring LSP w/o nvim-lspconfig is Simple!
This is not the case! After reading the LSP help pages (:help lsp), I installed and configured two language servers: Typescript Language Server for JavaScript and Pyright for Python. Neovim has fantastic defaults, so things like tags, omnicompletion, and semantic highlighting (New in 0.9) are enabled and configured by default as long as your language server supports them. You can see my configuration below.
- Which LSP Server for Python and JavaScript?
-
How to access tsserver code actions?
Open feature request to typescript-language-server or check corresponding implementaion in vscode and make a pr for it.
-
How do I achieve JavaScript code completition with nvim-cmp and Mason ?
Use mason to install tsserver, or directly install it on your computer following typescript-language-server. Note that your javascript's ls is powered by tsserver not eslint since eslint is a linter, not a ls.
What are some alternatives?
deno - A modern runtime for JavaScript and TypeScript.
nvim-lspconfig - Quickstart configs for Nvim LSP
null-ls.nvim - Use Neovim as a language server to inject LSP diagnostics, code actions, and more via Lua.
nvim-lsp-ts-utils - Utilities to improve the TypeScript development experience for Neovim's built-in LSP client.
nvim-lspinstall - Provides the missing :LspInstall for nvim-lspconfig
TypeScript - IO wrapper around TypeScript language services, allowing for easy consumption by editor plugins
neovim - Vim-fork focused on extensibility and usability
LunarVim - 🌙 LunarVim is an IDE layer for Neovim. Completely free and community driven.
coc.nvim - Nodejs extension host for vim & neovim, load extensions like VSCode and host language servers.
coc-tsserver - Tsserver extension for coc.nvim that provide rich features like VSCode for javascript & typescript
rust-analyzer - A Rust compiler front-end for IDEs [Moved to: https://github.com/rust-lang/rust-analyzer]
rust-analyzer - A Rust compiler front-end for IDEs