VSCode MDX suggestions

[remcohaszing]

I would like to align the vscode-mdx more with the unified ecosystem. IMO it currently contains a lot of unnecessary boilerplate. I have some suggestions.

Remove excessive funding information

I suggest we remove .github/FUNDING.yml, so GitHub falls back to .funding.yml in the .github repository.

I don’t know what the donate field means in package.json, but since it links to alternative funding URLs, I suggest to remove it entirely.

VSCode extensions don’t use the funding field in package.json, I suggest we remove that too. Instead, it uses the sponsor link.

I suggest to change the sponsor link from https://github.com/mdx-js/vscode-mdx?sponsor=1 to https://opencollective.com/unified, which is used consistently for the funding field throughout the unified ecosystem..

Remove simple-git-hooks and lint-staged

Some people like it, others don’t. Since these aren’t usually used in the unified ecosystem, I suggest to remove them.

Remove commitlint

I see value in checking commit message consistency in organizations or if they are used to generate changelogs. Since it’s not used for that in the vscode-mdx repo, I think it just heightens the bar for contributors.

Remove renovate

It’s typically not used within the unified ecosystem.

Switch from ESLint to XO

I personally prefer ESLint over XO, but for consistency within the unified ecosystem I suggest we use XO. If we don’t, I suggest we use a less bloated preset.

Switch to remark-preset-wooorm

This is used consistently within the unified ecosystem.

Switch from yarn to npm

Within the unified ecosystem npm is used consistently. Currently this is blocked by @lstg/common-config, which has incorrect peer dependencies.

Switch to official CLIs for publishing

Currentl the HaaLeo/publish-vscode-extension action is used for publishing. Instead I suggest to use the official vsce and ovsx CLIs.

Change master branch to main

Within the unified ecosystem we consistently use the main branch.

Remove lockfile

Although I personally like lockfiles, within the unified ecosystem they are typically omitted.

Keep changesets

I like automated releases. I think this can also be used for a mono repo, right? This is mostly relevant, because the addition of intellisense will make it a mono repo.

[wooorm]

Sure, I’m in favor, but I don‘t contribute to that repo a lot.

[ChristianMurphy]

Remove commitlint
Remove renovate

I'm somewhat fond of renovate bot and commitlint. 😅
But agree that unifying on the same set of tools could be a good idea. ✅

Switch from yarn to npm

Agreed.
I'd prefer npm as the primary package manager, the majority of users seem to use npm.
And yarn and pnpm, especially in plugin and play mode have a number of edge cases that differ from how npm works.

Switch to official CLIs for publishing

I haven't interact with these tools for publishing vscode extensions much.
But generally agree that using official implementations will likely work better.

Remove lockfile

I have mixed feelings.
I generally prefer to have lockfiles as well, to have a known good state, and have a way to trace which dependency changes could be causing issue.
But most of unified does not use lockfiles.

Keep changesets

I like changelogs and automated releases.
Though most of unified uses github releases, rather than a changelog file.
Also worth noting, if this is kept, it may be a good idea to pair it with commitlint so the commit messages can be structured well. Ideally much of that information would primarily/also be in the commit messages.

I don‘t contribute to that repo a lot

I‘m in a similar spot to Titus, I haven't contributed much to that repo.

[remcohaszing]

Remove commitlint
Remove renovate

I'm somewhat fond of renovate bot and commitlint. 😅 But agree that unifying on the same set of tools could be a good idea. white_check_mark

I like to write detailed commit messages and use them as the PR description. I also like to recpect to projects’ conventions, but sometimes I just forget to adhere to their commit message convention. When I write a 20 line commit message, but forget to use a header proper header, it’s annoying if commitlint and lint-staged refuse to commit and discard that commit message.

Personally I think tools like renovate / dependabot are a bit noisy. Usually it’s irrelevant if a vulnerability is found in a dependency of a dependency of a dev dependency.

Remove lockfile

I have mixed feelings. I generally prefer to have lockfiles as well, to have a known good state, and have a way to trace which dependency changes could be causing issue. But most of unified does not use lockfiles.

I share these mixed feelings. I still have the same opinion on this topic as I wrote in remarkjs/vscode-remark#83 (comment).

Keep changesets

I like changelogs and automated releases. Though most of unified uses github releases, rather than a changelog file. Also worth noting, if this is kept, it may be a good idea to pair it with commitlint so the commit messages can be structured well. Ideally much of that information would primarily/also be in the commit messages.

I also like changelogs and automated releases. Although I do not like it when combined with tools like renovate. IMO changes like “Update dependency some-package from ^1.2.3 to ^1.4.5” don’t belong in a changelog. I like the current approach of using changesets.

[remcohaszing]

@JounQin do you have any opinions on this? I’m mostly interested in your views, because you originally created that project.