External library curation or pre/post-moderation

[bisubus]

Some libraries (glaring example is angular.js) are abused extremely often. Extra js/css are added by some users who may think that files may fit their case. Or they cannot find their way through library editor, and library version ends up with blank fields. The last case is the worst - when a plunk is affected by semver, it loses relevant <script> tags on its load, and it is impossible to say which library is missing.

Right now angular.js has several 1.5.5 versions, all of them are junk. I've added 1.5.6 version to fit [email protected] restriction several days ago but found it today in bad health.

I'm not sure how this correlates with Plunker's traffic, but it became a real problem only in 2016.

Can the experience with libraries be improved, at least for selected commonly used libraries?

[ggoodman]

@bisubus I have revisited the entire approach to the package catalogue in the recently revisited https://embed.plnkr.co (see the book icon on any .html pane). This experience is driven by npm itself.

I will be porting that experience to plnkr.co.

Does this approach better reflect what you are looking for?

[bisubus]

@ggoodman, didn't know about revamped embed. Yes, I believe this may help. Will the packages be limited to the ones that are available through npmcdn? Some Node-first libraries (like co) are suited for browser usage and may be available as UMD modules on Bower (or cdnjs), but not on NPM.

[ggoodman]

@bisubus that is an interesting point you make. I don't think there is a single strategy that will work for everyone and for every package. I developed the plunker catalogue to fill a void in the capabilities of the different package repositories of the time. Given that curating a package repo would be an insane tax on my time, I decided to open it up to the community. There are two main problems with the system I built:

1. Bad actors in the community.
2. Poor UX design that doesn't help guide users to properly interact with the catalogue.

I decided that npm emerged as the authoritative source of javascript modules (both front and back end) and that integration with this would offer the best experience to users.

If the new npm integration doesn't work for certain modules, one of two things can be done:

1. Templates can be created to bootstrap correct usage.
2. Pull requests can be submitted to package authors whose packages are missing umd builds.

[bisubus]

@ggoodman, I agree that maintaining the library is a job for the community, not for one person. I'm not sure if this should be performed via UI or through community-driven repo, but there are people who use Plunker daily for work and are eager to help with that.

I think that CDNs (namely cdnjs, rawgit and wzrd.in) are still pretty good sources for almost everything that NPM cannot cover, it would be nice to still have an option to configure some libraries to fetch from there and not from npmcdn, if possible.

[ggoodman]

@bisubus I agree that the package catalogue would be best managed by the community. Unfortunately, I don't personally have time to develop the API and interface that would allow this to be done using tools like Github.

If the community were willing to work with me to build such a tool, I can absolutely see a hybrid approach working. I think that there is a lot of value in an npm-driven package repository that is automatically in sync with the authoritative package data and metadata.