Angular 13 ivy. Processing legacy "View Engine" libraries

[yuriy-bezrukov]

ng serve

⠹ Generating browser application bundles (phase: setup)...Processing legacy "View Engine" libraries:

-- ngx-perfect-scrollbar [es2015/esm2015] (git+https://github.com/zefoy/ngx-perfect-scrollbar.git)

Encourage the library authors to publish an Ivy distribution.

Please, update package

[sconix]

This package has been in EOL state for a quite while now as stated in the README.

[hakimio]

@sconix I understand that you don't want to maintain this package anymore but would you accept a PR if someone submitted one? It would require a major version bump of the library to support Ivy partial compilation mode though.

[sconix]

Its better that someone makes a fork out of this and releases that since at this point when library has been unmaintained for a while releasing PR's would still need testing, updating package version etc. I just do not want to maintain library when there are better options for it out there.

[hakimio]

I have tested ngx-scrollbar and wouldn't say it's any better. It's buggy and doesn't support a lot of scenarios which perfect-scrollbar does support.
Anyway, I can update ChangeLog, package.json, README, test the new version library on my project and make sure it doesn't introduce any breaking changes apart from higher Angular requirement if you are willing to merge the PR. I don't want to maintain a fork.

[hakimio]

@sconix so, is that a "no" for merging a PR?

[gethari]

@sconix so, is that a "no" for merging a PR?

Did you manage to fix the issue? Do you still have a fork ?

[hakimio]

@gethari I never created any fork since @sconix doesn't want to review it. "Fixing the issue" means upgrading the project from Angular 10 to 14 and setting compilation mode to partial. Feel free to create a fork if you have time for it.

[sconix]

This project is no longer supported as Readme states, I se no point for this kind of library anymore since there is much better options.

[hakimio]

@sconix if you don't want to maintain it, give the project to someone who does. Also, the only "better" option is WebKit CSS scrollbar customization or going with a UI library like Taiga UI or DevExtreme which include animated thin scrollbars.

[sconix]

There has been not a single volunteer for maintaining this in last few years and really as said do not see the point since a DOM based library is worst possible option when there are native Angular libraries available. Also when this library was ended even the perfect-scrollbar projects was without active maintenance. If it were in active development it would make much more sense to add Angular support into the library itself. Its really annoying to developer library on top of another without any support and only way to ensure the support would be to bundle it with the library itself.

[hakimio]

The ngx-scrollbar library you recommend doesn't even work correctly with a bit more advanced flex layout. Perfect Scrollbar just works fine as is, it doesn't need much bug fixing/maintenance. The only issue I experienced was fixed with a simple CSS workaround.
Anyway, I can upgrade the library when new Angular versions come out if you give me access to this repository and npm.
If you don't want to do anything with the library, maybe just archiving the repo might be the best option?

[sconix]

Works just fine in our project which has very complex flex layouts, but of course no libary is perfect and perfect-scrollbar is far from it as well (at least when we still used it do not know it current situation have the bugs been fixed or not). Nothing prevents you making a fork of this and publishing it to npm. Some day will most likely archive this, but for now there are still projects that use this so do not see the point of archiving since it would force those to update.

[ryders]

@sconix @hakimio if I may add my 2 cents...

Nobody cares about which library works better, and why, and why not, and under what circumstances. This is a pointless argument as essentially subjective, and so let's not waste time comparing apples to oranges.

@sconix I completely understand that your priorities may have changed and you find yourself with no time to maintain this. Given there seems to be a lot of people using this package, the right thing to do would be handing over the repo or allow contributors. Same for npm release. the idea of "forking and creating a new npm bundle" while technically feasible, is also wrong and forces the "~500k download per week" to search for alternatives, forks or not.

The main argument here is:

There has been not a single volunteer for maintaining this in last few years

@hakimio is this not something you can do?

[ryders]

@sconix further to this, if you are looking for volunteers to help and maintain this, may I suggest updating the read me to reflect as such? Currently, the EOL notice reads more like a "yeh nah whatever figure it out folks" than a "do you think this code should live on?!" 😉

[sconix]

Well the thing is that I do not think this code should live on. Using DOM based librariers with Angular is always a compromise with performance and does not just make sense when there is better none DOM base solutions out there. There was not when this library came to life, but now there is. That being said if someone disagrees they are free to make a fork and star maintaining it.

[ryders]

I don't understand enough of the performance implication of DOM libraries, and I can certainly understand there would be possible drawbacks. -- I must admit, I 'm actually quite curious, although a little time-poor at the moment. 🤦‍♀️😆

The argument against forking (and instead delegating / handing over) is really that there are arguably 100s of thousands -- if not millions -- of active installs for this package, and you're suggesting that your decision should prevail over everyone else's.

I absolutely get that handing over means someone needs to take it on. What I don't get is why you would care to keep the repo and npm packaging access. If someone judges there's plenty of value in there to invest their time, is that not their own decision to make and should the broader community not "benefit" from this? (despite the possible drawbacks)

@hakimio Alternatively, if you were to fork and create an alternative package, @sconix might be willing to update the README here in order to directly point users to the replacement package?

[sconix]

I can not hand over this repo naturally since could not risk that somebody would use it wrongly hence forking is the way to go in these cases. Its the simplest job of changing the package name in package.jsons if somebody forks this library so the number of installs out there does not matter.

And of course if there will be a maintained fork of this I can add info about it into the README. I have nothing against of this library living on just that I see no point for existence of this library and therefore wont be using my time to maintain it its that simple.

[ryders]

that somebody would use it wrongly

Oh my -- you're being difficult here, Janne!

I have nothing against of this library living

At this point, I beg to differ.

Be well.

[ryders]

@sconix please consider marking the npm package as deprecated -- as per https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions

Additionally, should gethari/ngx-perfect-scrollbar meet your standards, you would be so kind as to add a link to the repo and npm package.

[hakimio]

@ryders feel free to create a fork. I don't really have time to maintain another project right now myself but I could contribute to your fork with some PRs.

[ryders]

@hakimio see my comment right above, gethari/ngx-perfect-scrollbar has already created one, and also published a npm package for it under perfect-scrollbar-angular. Amongst others.

There's already plenty of forks it seems, and I'm only now just hoping the here will do the right think and clean this up. imho adding 1-line to a readme file is not sufficient and not helpful to the community.

[sconix]

@ryders I am not being difficult it has happen many times that npm package has been handed over and that package has been used for malicious purposes. I have no intent at all being difficult just trying to help the coders to do the right thing and not use this kind of libraries its not good practice in anyway when there are better options. But again I am not trying to force anyone to do the right thing its a free world and everybody can use any library the way they see best fit, thats why I have left this library alive since there are plenty of projects it still works (not all use latest Angular version etc.).

Package has been marked as deprecated now and I have added a line in the readme saying that there are forks if someone really wants to use this kind of library.

[hakimio]

Here is a CSS only solution to create a custom scrollbar with changing width on hover for those who don't want to deal with ugly JS solutions. Works on all modern browsers except Firefox (Firefox users get slightly thinner scrollbar and it seems that Firefox developers plan to implement -webkit-scrollbar in near future anyway), but the width and color transitions are not animated.

::-webkit-scrollbar {
  width: 14px;
  height: 14px;
}

::-webkit-scrollbar-track {
  background: transparent;
}

::-webkit-scrollbar-thumb {
  background-color: rgba(202, 202, 202, 0.6);
  border-radius: 14px;
  border: 4px solid transparent;
  background-clip: content-box;
}

::-webkit-scrollbar-thumb:hover {
  background: #cacaca;
  border-radius: 10px;
  border: 2px solid transparent;
  background-clip: content-box;
}

/* Firefox only */
* {
  scrollbar-width: thin;
  scrollbar-color: #cacaca transparent;
}

Demo: https://codepen.io/hakimio/pen/yLjezzY

[swapnilfarande]

@gethari https://www.npmjs.com/package/perfect-scrollbar-angular package doesnt work properly. I guess you published package on npm from root directory. Can you build the package again and publish it from dist/lib directory?