Suggestions: Discuss possible directions for improvement

[ffgan]

I like this project very much and hope to make more contributions to it. I have noticed a few more PRs recently, and I think if we can discuss some possible improvement directions and then split them into small goals, so that some new contributors can be attracted to participate, I am certainly happy to complete these goals. In the longer term, if there are more contributors, maybe we can create a separate organization for the current repo, which will attract more users, instead of being regarded as just an individual project that may be stopped from maintenance.

I think a more likely direction for improvement is to check whether there are more modern components / dependencies and try to migrate the past, such as src/muya. Of course, this will be difficult, but with further discussion, maybe we will reach more consensus to better promote the development of the project.

[Tkaixiang]

Hi @ffgan I think that's a great idea - I will get to setting up a Projects board so people get better contribute to issues/features we want for the next verison.

As for Muya, do you have any alternatives or suggestions? I do however believe that it is the core of MarkText, and what makes it worth using. I personally started this project because I really liked the existing abilities of Muya compared to other editors such as Obsidian. The way it formats things and the abilities baked-in without needing to use any plugins is a huge plus for me.

[ffgan]

I’m not entirely sure about the current status of the src/muya directory in our repository. It appears that the original Muya from Marktext is still being maintained, and its primary language is TypeScript. I’d like to know your thoughts on this.

[Tkaixiang]

Oh I did not know that! Typescript is definitely a huge step up from what we have.

We do have a few improvements over the original Muya, so a proper diff analysis using an AI agent will be needed to see what bug fixes we should port over.

This should work out of the box natively as Vite already supports importing .ts in our existing .vue and .js files

[ffgan]

Personally, I think we should be able to eliminate a significant number of dependencies, since Bun comes with quite a few built-in tools. Plus, Bun is quick to install and build. Of course, maintaining the status quo is the best option; I’m just suggesting this as a possible direction for improvement.

[ffgan]

You could try building Marktext locally using Bun; I think it’ll help you get a feel for how convenient Bun is.

[ffgan]

You can check the CI files here; all you need to do is switch from Node.js to Bun.

The only issue arises when installing dependencies.

npm ci --no-audit --no-fund --ignore-scripts --loglevel verbose

When I switch to bun, an error is reported upon execution.

$ bun ci --no-audit --no-fund --ignore-scripts --loglevel verbose
bun add v1.3.13 (bf2e2cec)
error: GET https://api.github.com/repos/substack/sockjs-client/tarball/browserify-npm - 404
error: sockjs-client@git://github.com/substack/sockjs-client.git#browserify-npm failed to resolve

However, if simply run bun ci --ignore-scripts, everything will go smoothly. This is exactly what I did in the CI link mentioned earlier

[ffgan]

For the most recent build using bun, please refer to this link: https://github.com/ffgan/marktext/actions/runs/24925800857

[Tkaixiang]

Thanks, I will take a look at it when I have a bit more time

[Tkaixiang]

Hi I have created a project version planning here: MarkText Version Planning (view)