updating, reducing dependencies#9
updating, reducing dependencies#9trevorhreed wants to merge 1 commit intobusterjs:masterfrom trevorhreed:master
Conversation
|
Did you try running the tests locally? I think there needs to be a bit of maintenance done to the repository, before this can be made to pass. Would you be up for doing that also? |
|
Possibly. It appears that travis-ci and appveyor are running things against old versions of node, but I think it might be running a newer version of npm than is supported. The scripts/configuration on travis/appveyor may need updating as well. What's the minimum version of node that you would like to continue supporting? |
|
A bit of background, the main project under this GitHub organisation: buster has been discontinued. Some repositories have been moved to the However, none of the Would love to hear from some of the other @busterjs/owners, perhaps @dominykas has an opinion on whether or not to continue maintenance on the Do you use
Just the LTS versions, so that would be 6 (until April 2019) |
|
According to https://www.npmjs.com/package/multi-glob?activeTab=dependents this project has 50 public dependents. |
|
I have recently found a suitable alternative ( |
|
Perhaps @stephenmathieson or @thomas-darling could comment on whether or not they are planning to maintain |
|
I do not have intentions of maintaining the |
|
Apparently the travis config needs to be updated as well. |
But it also has only 18k weekly downloads and it hasn't been updated in 3 years and most of the packages that depend on this have also not been updated in over a year, so I wonder if this should just be marked as deprecated? And the updates that it had also have not changed the main file - which is now 6 years old... The code itself is less than 50 lines of code - easy enough to fork and publish, whereas maintaining this would mean upgrading the node versions, changing the test framework and doing quite some cleanup. I'm not sure it's worth it. At the same time, given last month's fun with event-stream, I'm not sure that handing over to a new maintainer is best practice either, so I'm saying that someone should fork this, if they want to, and we can add a link to the new package and alternatives in the readme and the deprecation notice? |
|
In fact, I think all of busterjs organization should be marked as archived, and all its packages should be marked as deprecated. @mroderick what do you think? I can probably find time for that this year. It's been a good run - it's time to retire, there's plenty of alternatives. |
|
I don't disagree fwiw! We started Buster when the only alternatives were QUnit and jsTestDriver, but there are plenty of great options out there nowadays. And a valuable lesson of shipping sooner and building iterative traction, rather than spending time on perfecting stuff and not releasing it, was learned by yours truly :) |
|
I agree that archiving these repos would be the right thing to do given that they are truly abandoned (except for the modules expertly curated by the sinonjs crew under @mroderick's leadership). Still, I think removing a module that have 50 dependents and "just" 18k weekly downloads is a bad idea. Our industry suffers way too much breakage already, let's not contribute to the bonfire. I made a pass at fixing the issues raised in this PR over here: #11 If someone with the keys to the castle could be bothered to merge and release to npm, then 👍 |
|
Just to make sure - I wasn't suggesting removal, only adding a deprecation notice that this is no longer maintained. I have to 🙇 down to @cjohansen for taking the time to do a cleanup PR, though - I'll merge and publish. |
|
We can move it into the @sinonjs organisation, it has several orphaned projects already.
Sent from phone, apologies for brevity and auto-correct weirdness.
… On 11 Dec 2018, at 11.42, Christian Johansen ***@***.***> wrote:
I agree that archiving these repos would be the right thing to do given that they are truly abandoned (except for the modules expertly curated by the sinonjs crew under @mroderick's leadership).
Still, I think removing a module that have 50 dependents and "just" 18k weekly downloads is a bad idea. Our industry suffers way too much breakage already, let's not contribute to the bonfire. I made a pass at fixing the issues raised in this PR over here: #11 If someone with the keys to the castle could be bothered to bump the version to 1.0.2 and release to npm, then 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Awesome @mroderick! Even though it isn't "actively maintained" - it really is done, and now it has running tests. No point in keep poking at it. If people use it, let 'em. |
|
@mroderick shall I add you as an owner on npm? |
yes please |
|
We should probably also transfer |
|
Perhaps we can get a couple of maintainers to go with the new packages? ;) |
|
Rather than dragging |
We're still trying to keep |
|
In any case, I think it would be a good idea to start marking the unmaintained repositories under |
|
@mroderick added you on We don't strictly need to transfer I'll go through the remaining repos and archive them on GH and deprecate on npm at some point later. |
8 participants
The version of lodash being used in the published version of the
multi-globnpm package has a serious security vulnerability. This pull request updates that dependency. In addition, instead of requiring the entire lodash library, this update requires only those portions of lodash that are necessary.