search

hoffi / gulp-msbuild

gulp-msbuild has moved to https://github.com/fluffynuts/gulp-msbuild.
MIT License
53 stars 44 forks source link

Support vs2019 msbuild (16) #76

Closed fluffynuts closed 5 years ago

fluffynuts commented 5 years ago

I've made some logic changes to support vs2019, tested against VS Build Tools 2019. ToolsVersions of 'auto' and 16.0 should select msbuild 16 when installed.

I've also tested with only VS Build Tools 2017 installed, where 'auto' invokes msbuild 15.0

Test-wise, I've added two conditional tests which are only invoked when vs2019 is found on the host machine. I'd prefer to have more "mocked" tests, like the originals but with the auto-detection now also attempting to invoke msbuild to get a version, it's going to take a little more time and effort.

Since the original project is no longer maintained, I'd also like to advocate for me to take over maintenance and package updates, if you're ok with the changes I've made.

I tried to keep the impact I had on these files are minimal as possible, so as to make the PR easier to deal with.

coveralls commented 5 years ago

Coverage Status

Coverage decreased (-14.3%) to 76.981% when pulling ca1af294b26354e39ecc9d03aec9f3fc697ee07d on fluffynuts:support-vs2019 into f1c78e79d1751a077c336529f3bbccc8509d5f2b on hoffi:master.

coveralls commented 5 years ago

Coverage Status

Coverage decreased (-14.3%) to 76.981% when pulling ca1af294b26354e39ecc9d03aec9f3fc697ee07d on fluffynuts:support-vs2019 into f1c78e79d1751a077c336529f3bbccc8509d5f2b on hoffi:master.

coveralls commented 5 years ago

Coverage Status

Coverage decreased (-14.3%) to 76.981% when pulling ca1af294b26354e39ecc9d03aec9f3fc697ee07d on fluffynuts:support-vs2019 into f1c78e79d1751a077c336529f3bbccc8509d5f2b on hoffi:master.

hoffi commented 5 years ago

Okay, thanks :) I will merge and publish it as 0.6.

Since the original project is no longer maintained, I'd also like to advocate for me to take over maintenance and package updates, if you're ok with the changes I've made.

Sure 👍 I would update the readme to only link to your fork as new repo. I can then transfer the npm package to your username, so you can publish new versions.

fluffynuts commented 5 years ago

@hoffi I appreciate it (: gulp-msbuild forms an integral part of our modular zero-conf or near-zero-conf build -- I have a github repo (https://github.com/fluffynuts/gulp-tasks) which provides a modular, easily-overridable build / test system for dotnet (framework, and recently, core), supplied via git submodule. Your work on gulp-msbuild has been an integral part of that repository since 2016, across two orgs I've worked at. So yeah, it's kinda important to me (:

I'm sure it violates a lot of the principles of the original gulp team -- in particular, I shim out gulp4 to allow forward-declaration of tasks, easy insertion of help text, and the ability to retain gulp3 syntax with gulp4 (since gulp3 now errors on older (read < v10) versions of node). And I rely heavily on your "black-listed" module. I'm ok with the divergence in philosophy -- I want to enable easy extension & overriding of tasks within the chains, with as little config / work as possible for consumers (using convention over configuration) and the gulp team wants to optimise for speed, which isn't a bad thing, but the two objectives are not necessarily always aligned (:

hoffi commented 5 years ago

Sure 👍 I would update the readme to only link to your fork as new repo. I can then transfer the npm package to your username, so you can publish new versions.

Just done. You should now have access to publish a new version of the npm package. I have also changed the readme in this repository to only contain a link to your repository :)

fluffynuts commented 5 years ago

Thanks! Apologies for the late response: this has been yet another time that an important GitHub notification has slipped by in the flurry of others that I get every day ): I've also had some recent health issues which put a bit of a speed bump in my path, but I'm getting back up on my feet (:

I actually came back to this thread to suggest a possible alternative solution - that I package under a new name and you could mention the name in your readme, primarily after all the recent "new developer X takes over existing package to publish malicious code" stories - I'm acutely aware of how unfortunately little we can trust in the open-source is community. I'd be sceptical of a change of ownership, though I guess if I wanted to be nefarious, I could have already done so in synchronous-promise (: still, there's a trust issue in the JavaScript open-source community (not completely unfounded) and I don't want to trigger anyone.

My biggest problem with that approach is that I literally couldn't think of a reasonable name ):

But now that I've read this, I hope to make a release soon, just to update the readme to say that it is now maintained again (: perhaps tonight (:

I'd like to thank you for all the hard work you've put into this package, and for allowing me to continue with it. I hope to carry the torch well.

hoffi commented 5 years ago

Thanks :)

That would be fine too. Yeah a good name would be hard to find indeed. Just let me know when you have one and i can update the name here :)

fluffynuts commented 5 years ago

It's fine - I've updated the readme to note that the project is maintained and have pushed a minor package update so that's reflected at npmjs. I'm quite sure my intentions are not nefarious as I have several build pipelines which depends on this 😁 and now I can respond (hopefully quickly) to any issues I (or others) encounter. Thanks again.