Rename vscode-remark to remark

[remcohaszing]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

The extension id is ${publisher}.${name}, so for this plugin it’s unifiedjs.vscode-remark. This id is used in some places, such as installation instructions and configuration of the formatter once #65 is finalized.

I.e.:

ext install unifiedjs.vscode-remark

"[markdown]": {
    "editor.defaultFormatter": "unifiedjs.vscode-remark"
}

I think the vscode- prefix is a bit superfluous in this context.

Solution

1. Rename this extension from remark-vscode to `remark
2. Unpublish the old extension
3. Publish the new extension

Alternatives

Keep it as-is.

[ChristianMurphy]

🤔 looking at how other plugins are named.

Several similar/related plugins seem to use the vscode prefix:

• https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint
• https://marketplace.visualstudio.com/items?itemName=stylelint.vscode-stylelint
• https://marketplace.visualstudio.com/items?itemName=JounQin.vscode-mdx
• https://marketplace.visualstudio.com/items?itemName=eg2.vscode-npm-script

and one used it as a suffix https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode

I'm open to removing the prefix, but looking at common conventions, it seems many popular/official extensions do use the prefix.

[remcohaszing]

I figured out 34 of my installed extensions use the vscode- prefix, and 45 don’t. Both camps include popular as well as unpopular plugins, even from Microsoft. IMO that’s pretty much even.

I still think it’s prettier to remove the prefix, but it’s not a big deal.

[Murderlon]

I don't have a strong opinion on it but I'm not sure how many users are affected if we unpublish the current plugin just for a name change.

[wooorm]

👍 on murderlon’s point: changing would introduce churn, which i’d weigh heavier than the “slightly prettier”?

Btw, I believe one of these VSCode-related projects (maybe this one?) has to get a new name to be published under unified, because vscode can’t grant published artefacts to new folks?

[Murderlon]

Btw, I believe one of these VSCode-related projects (maybe this one?) has to get a new name to be published under unified, because vscode can’t grant published artefacts to new folks?

There are already two, one from mrmlnc, and one from us.

[remcohaszing]

Btw, I believe one of these VSCode-related projects (maybe this one?) has to get a new name to be published under unified, because vscode can’t grant published artefacts to new folks?

There are already two, one from mrmlnc, and one from us.

The one published by unifiedjs isn’t that popular though (327 installs). Probably because it just doesn’t work with the unifiedjs ecosystem moving towards ESM and VSCode not being able to handle it.

There are also stefanprobst.remark-lint and drewbourne.vscode-remark-lint which suffer from the same issues.

There’s also https://github.com/mdx-js/vscode-mdx.

---

I’m getting vibes most prefer to not rename it. This is ok, the name isn’t that bad, but if it’s going to be renamed, I think now would be the right time.

[wooorm]

/cc @stefanprobst @drewbourne

[wooorm]

The plan was to deprecate mrmlncs one in favor of our new package: #44 (comment).

[remcohaszing]

Since this is really minor and I’m sensing more pushback than support for this, I’ll close this issue.

[drewbourne]

@wooorm is there a request here for me to unpublish the drewbourne.vscode-remark-lint extension?

I haven't tested or used the extension in a few years due to some rough edges with loading/reloading the configs for remark, retext and custom dictionaries. I do think there is value in enabling some of the fixable / autocomplete features from remark & retext in a VS Code extension.

[remcohaszing]

@drewbourne

@wooorm is there a request here for me to unpublish the drewbourne.vscode-remark-lint extension?

I haven't tested or used the extension in a few years due to some rough edges with loading/reloading the configs for remark, retext and custom dictionaries. I do think there is value in enabling some of the fixable / autocomplete features from remark & retext in a VS Code extension.

#65 introduces feature parity with your extension and more (including loading of ESM configurations 😄 ). I suggest you unpublish drewbourne.vscode-remark-lint after those changes have been published. However, until then I think your extension is the best option out there for people willing to use older (CJS) versions of remark plugins. So I recommend to wait for that.

[wooorm]

It was firstly a friendly ping to share some info!

But I think so. As Remco comments, this updated package is much improved and does what your extension does (and much more).
I’m not sure what the best way is to deprecate a package and suggest an alternative though.
Perhaps publish an empty package with just a readme pointing to this project?