Rename repository to `mdx-analyzer`

[remcohaszing]

This repo started as a VSCode extension that adds basic MDX language support. Currently it includes a language server and Monaco editor support. Only the MDX VSCode extension is published yet, but I intend to change that at some point. I think it would be better to name the repository to mdx-intellisense.

[wooorm]

What’s the scope of this repo? Why are those not in different places? Why not in the MDX monorepo (probably gets too big there, as everything has very different dependencies that would need to be installed)

[remcohaszing]

The scope, or at least my goal, is to provide a rich editor experience. LSP allows to write this once, then re-use it.

Some editor integrations keep a big list of language servers (emacs-lsp, nvim-lspconfig, vim-lsp). For those it’s sufficient to publish the language server.

Other editors require an extension manifest, like VSCode. Not only is this the way to package the language server for VSCode, but it’s also the simplest way to debug it. I could imagine we may want to add support for some other editors as well, such as IntelliJ or Sublime, although those might be better developed externally, as they are based on different programming languages.

Monaco editor doesn’t use the language server, but it does use the language service, which is also an important part of the IntelliSense. Similarly IntelliSense for CodeMirror fits in this scope, but I currently have no personal interest to work on this at the moment.

Keeping all this together makes troubleshooting a lot easier.

The mdx monorepo focuses more on building / compiling / processing MDX.

The eslint-mdx monorepo focuses specifically on ESLint integration.

[wooorm]

So you see the word intellisense as overarching language servers and monaco (and codemirror)? The IntelliSense term seems to be linked to VS Code. Why not a different term, more relating to editors?

[remcohaszing]

Indeed, good catch! I’ve been using the term IntelliSense for smart editor features, but it’s indeed linked to VSCode (and Monaco editor) specifically. It’s used in the LSP specification once, but that appears to be by accident.

I’m open to other suggestions. Some ideas:

• mdx-intellisense (I just got used to the name :shrug:)
• mdx-lsp
• mdx-ls (Read as either language server or language service)
• mdx-editor
• mdx-language-features

[wooorm]

What about mdx-analyzer, sort of like https://github.com/rust-lang/rust-analyzer?

[remcohaszing]

Another potential use case would be a CLI. This CLI would be like tsc, but it can handle MDX files. This means MDX type-safety can be checked in CI. Perhaps it could also build the MDX and even emit .d.ts files. Also maybe mixed in with unified-engine functionality? I don’t know exactly what this would look like yet.

[wooorm]

• would probably be nice to move to mdx-lang maybe as an org name? 🤔 especially now with rust
• a nice CLI is a great idea! Could have lots of features though. So bit vague.

/cc @ChristianMurphy

[remcohaszing]

What about mdx-analyzer

I see why the term mdx-analyzer, but to me it sounds like some tool to generate reports, not editor support.

What about: mdx-ide?

• would probably be nice to move to mdx-lang maybe as an org name? :thinking: especially now with rust

I never really liked the mdx-js name, because like I don’t js in package names in general. This is implied if it’s in the JavaScript ecosystem. :sweat_smile: I would like the name mdx both as an npm scope and and a GitHub organization, but it’s taken in both places. I think it’s best to stay in the mdx-js organization for now. It’s also the name people already know.

• a nice CLI is a great idea! Could have lots of features though. So bit vague.

Yeah, definitely vague yet.

[wooorm]

I really really like analyzer myself. That term is more about what the things in this repo do. I also like the precedence with rust-analyzer. This sounds like exactly what we want to do here.

lsp, ls, intellisense have the same problems that the current name vscode has: they are too much tied to one particular part of what’s needed. That makes it harder in the future if something other that LSP comes around and we’d want to support that too.

language-features is a bit vague, that could be something like YAML frontmatter or GFM.

ide, editor are not bad. Though a thing like mdx-editor could be interpreted as being an editor itself. “Integrated development environment” is a bit jargony for me. It also implies something to me that “normal” editors don’t have. But we do want to support “normal” editors too (e.g., with syntax highlighting)?

On that TM language here, that’s quite interesting. I can somewhat understand that in mdx-analyzer (and mdx-editor). But less so in mdx-ide, mdx-lsp, mdx-ls, mdx-intellisense

[ChristianMurphy]

intellisense

I also have mostly heard of this as a Visual Studio (and more recently a Visual Studio Code) term.

editor

If this project plans to be focused on IDEs and editors, editor makes more sense to me.

analyzer

I like this if the expanded idea of having a CLI or other ways of interacting come into play. This feels more comprehensive than intellisense or editor, while still capturing the core idea.

would probably be nice to move to mdx-lang maybe as an org name?

I'd be good with that. Does mdx-rs have plans to move into the new org? (or the existing one?)

I think it’s best to stay in the mdx-js organization for now. It’s also the name people already know.

My gut reaction is I'd prefer to stick with the current org name rather than migrate as well. But I remain open to moving stuff over.

[wooorm]

I'd be good with that. Does mdx-rs have plans to move into the new org? (or the existing one?)

Yes.

---

mdx-lang

I just checked with John, who thinks it’s a good idea, and reminded me that we had already talked about it at length before. So perhaps this is a bit “out of the blue” for you while feeling very natural to me.

[remcohaszing]

I like the new name for the GitHub repo, but I also like that the npm scope and GitHub organization match currently. Do you have any plans to change the npm scope too? Changing that would impact many users.

[wooorm]

I like the new name for the GitHub repo

Which one?

I also like that the npm scope and GitHub organization match currently

Not really. Though I don’t particularly like mdx-js. The -js suffix feels superfluous to me. It makes some sense for mdx-js/mdx, but not so much for WASM builds of mdx-rs, or this repo (vscode-mdx or whatever it will be called).

[jasikpark]

mdx-js/mdx-analyzer

• cli type checker
• vscode extension w/ intellisense
• lsp allowing vim and other editors to have good MDX support

[wooorm]

@jasikpark i think this is a comment in favor of mdx-analyzer, right? but not particularly against mdx-lang? Or am I misreading?

[jasikpark]

erp yeah 😆 mostly just trying to solidify what the whole conversation was here

deff like a "here's mdx tooling" as a repo name

i think it makes more sense to change the repo name b4 messing w/ the org name / npm scope

good example of a scope that works imo is: https://astro.build uses withastro/astro on github, astro is a non namespaced package, and then packages are namespaced under @astrojs like @astrojs/mdx for instance xD

[wooorm]

Yep, agreed. I don’t think this issue needs to be about org name (mdx-lang) / npm scope (?). Just this repo.

[remcohaszing]

It appears mdx-analyzer is the most popular name, so let’s go with that. I suggest to rename this repo when moving it into the mdx-lang organization. Some repositories may reference files within this repo. (https://github.com/shikijs/shiki/issues/237)

[wooorm]

Shiki uses the different repo still?

[wooorm]

Oh it just switched. Anyway, we can PR that?

[remcohaszing]

I’ll gladly PR Shiki when we switch.

[wooorm]

What I mean is, we can change this repo now, and PR. And then change the org name in 3 months. And then if needed PR again

[remcohaszing]

We could do that too, although I’m not that much in a hurry to rename.

[wooorm]

I don’t see a good reason for waiting months. I don’t understand why you want to wait: are you worried about the work it will take you to rename this repo? If that is the case, I would like to do it. Or are you worried about something else?

[remcohaszing]

I just prefer renaming once over renaming twice. Moving into another organization is also a rename.

If you really want to rename now, it’s not that big of a deal, but personally I’d combine this with moving into the mdx-lang organization.

are you worried about the work it will take you to rename this repo?

No, actually I don’t even have the permissions do do this. :sweat_smile:

[wooorm]

I see things separately. This project has a wrong name that can be improved which will help people find it and understand what it is. This is an open issue that can be solved.

GH will do redirects anyway. The other change does not yet have an issue, and might take months.

Ok, I’ll do the rename!

[remcohaszing]

I must say after all this time I’m still not used to the name mdx-analyzer.

Since this repo uses Volar, it’s mostly synonymous to https://github.com/withastro/language-tools and https://github.com/vuejs/language-tools. I like the name language-tools.

[wooorm]

Wild, reading this thread again, I am extremely glad it’s mdx-analyzer and not something else!

Astro and Vue are more frameworks. That also happen to have some combination language too. So using the word “language” makes more sense. Tools seems vague to me. Every project under unified is a “language tool”.