Absorb or Merge with benalfree/mdsvex-enhanced-images

[lzinga]

This is an issue to contact @benallfree regarding his project github/mdsvex-enhanced-images and see if we want to merge our projects in some way or another.

It looks like mine was created a month before his but his might be a little more well written with 100% typescript. Although I enjoy having a project under my name, I would much rather not have a duplication of work happening on what is essentially the same thing.

If you are interested give your opinion on which project you would prefer to remain with. There is always the possibility of keeping both but know that can take enhancements and resources from one project usually leaving one dead compared to the other.

[benallfree]

Thanks I didn't even know there was another project. Since my repo seems a little more active, I'm happy to make you a maintainer if that would help preserve attribution in some way.

I'm curious, does your code do anything differently or add features we haven't considered?

[lzinga]

One of the big changes currently being made (hasn't been merged yet) is #3 which I think adds a great ability to let the user have more global control and local control of the images themselves through url parameters.

This feature also doesn't break the markdown itself by redesigning or changing how the markdown itself works.

[jimmux]

If I may, the path resolution in @benallfree 's project looks great, and will be essential for my needs. As are the improvements in #3 . Consider this an enthusiastic +1 for merging one way or the other!

[0gust1]

Sorry for the delay, I'm also all in for "merging" the repositories (whatever how we technically do it).

• I prefer typescript (full TS or JSDoc), especially for libs and mid/long-terme maintenance
• The features @jimmux and I introduced are really nice and interesting for users and content authors.

I'll let @benallfree and @lzinga work the modalities, but I'm available and motivated for help, improvements and contributions (my next focus points were typing, tests and automation (CI/CD)).

[0gust1]

@jimmux

If I may, the path resolution in @benallfree 's project looks great, and will be essential for my needs

Could you develop / explain the use case ?

In the current repo, we have an improvement to do:

the code begin with if (node.url.startsWith(".")) {...}, so we ignore any non-relative paths (including aliased paths which could be configured through svelte/vite config).
ref:

mdsvex-enhanced-images/index.js

Line 12 in 1058dcd

if (node.url.startsWith(".")) {

Let's say we handle this better in order to correctly handle relative paths and aliased paths (thoses defined in svelte(kit) and/or vite config).

Now, which use-cases are not covered by the native vite/TS resolvers, that could require a custom resolver passed to the plugin config ?

[jimmux]

@0gust1 My users are currently using Pages CMS to create content. It doesn't support relative paths in the configuration for images.

I'm not considering this such a showstopper now though, as it's still early days for this project. We may switch to other CMS options, or I will simply disallow images in markdown bodies. Consider this feature downgraded to nice-to-have for me.

[0gust1]

I think the next thing I'll look at is the import path management.

I really would like the users to be able to use project-defined vite aliases (as opposed to an ad-hoc resolver just for the plugin). It may be (partly?) the purpose of benallfree's customizable import resolver (I forked his repo yesterday, to take a closer look).

@jimmux I took note. I may ask further questions later (comment helped but wasn't precise enough for me ^^).

For merging/absorbing, I won't be technically hard, either way (I just tried a typescript conversion on a local branch)
I would just advocate to take care to properly credit all contributors (not only merged code commiters).

[lzinga]

@0gust1 since you have been an avid contributor to this project what are your thoughts on it, would you prefer to stay in this repo and merge content over from the other repo or vice versa? From my viewpoint it seems like it would be less work to merge the changes from the other repo into this one. Especially if you are already working on a typescript conversion and this project already has more features.

Ultimately there is nothing wrong with having two libraries that do similar things. It would just mean eventually one would be used more than the other dependent on features.

I agree that proper contributions should be called out, I had planned to integrate something like https://github.com/marketplace/actions/contribute-list into the project as an added reference to people who have helped. I believe there is also a way to add contributors to the npm package details as well but have not looked into that.

[benallfree]

This feels like it's leaning more toward absorbing my repo into this one, which is fine with me. lmk what you all decide :)