[Proposal] Replace UnCSS with fork

[NovaAtWarren]

I've created a fork of UnCSS to try and update some of the insecure dependencies, and to merge some PRs, as the original collaborators seem to not be performing said task.
As UnCSS (the version referenced by package.json) is unmaintained, and my fork is maintained, it may be a good idea to switch to decrease dependency on outdated packages.
I can make a PR if you desire.

[SukkaW]

@NovaAtWarren What happened to the uncss? The package is not maintained anymore? Why don't you open a PR to uncss instead of maintaining your own work? If uncss is not actively maintained, should we remove the uncss plugin in the next major release?

[NovaAtWarren]

What happened to the uncss?

Collaborators with NPM access seem to have either stopped programming JS or just gone AWOL, as per this issue

Why don't you open a PR to uncss instead of maintaining your own work?

On the 18th May, I opened pull 456, and while it got approved it never got merged.
There's a very basic fix that had a pr opened in December of 2020, which still hasn't been merged.

If uncss is not actively maintained, should we remove the uncss plugin in the next major release?

I can't comment on removing UnCSS entirely, as I'm unfamiliar with alternative packages, I just know that some of my dependencies use UnCSS, and maintaining a version with updated dependencies was easier than replacing it in every dependency that used it.

[maltsev]

@NovaAtWarren I appreciate that you forked uncss and upgraded it! But let me be honest with you, I'm hesitant to replace the original uncss with a forked version that is not actively used by other people and which future is also unclear (e.g., will it be maintained in the future, etc).

I'm not that familiar with the advanced features of npm, but maybe there is a way to replace uncss with your forked version on a per-project basis (peerDependencies?). Then I could mention your fork in the readme, so if people want they can use uncss.

I'm also open to other solutions!

[NovaAtWarren]

I can understand your hesitation entirely.
In this case, maybe a .patch and a small section in the readme, stating what it updates and why you might like it?

Edit: Additional idea, a forked-uncss branch. Whether I had write access or not, I could set a watch on this repo and just make a PR or pull changes across as and when they happen. Then, anyone installing the dependency doesn't have to modify it. They can just pull a different version (or a slightly different name on NPM)

[maltsev]

In this case, maybe a .patch and a small section in the readme, stating what it updates and why you might like it?

Sure. Sounds good to me! Would you provide it, please?

Additional idea, a forked-uncss branch

Sorry, I'm not quite sure how this would work. But, I think, it also sounds good to me!

[NovaAtWarren]

Sure. Sounds good to me! Would you provide it, please?

Sorry if I implied you'd make the patch, I do intend on writing it myself.

Sorry, I'm not quite sure how this would work. But, I think, it also sounds good to me!

What I was thinking with that was making a new branch on this repo, and applying the patch to that branch. Uploading that branch to NPM whenever package.json > version is updated or pushing manually, and having me make PRs from main to the branch to keep it updated.
Now that I've slept on it, though, I'm not as sure it's a good idea.

I'll get working on the patch

[maltsev]

Thanks a lot!