Change tool name from dotnet-fsharplint to fslint #778
Conversation
webwarrior-ws
force-pushed
the
tool-name
branch
from
18ecf92 to
b4acb3e
Compare
|
@Numpsy can you review? |
knocte
changed the title
| <PackageType>DotNetCliTool</PackageType> | ||
| <PackAsTool>true</PackAsTool> | ||
| <AssemblyName>dotnet-fsharplint</AssemblyName> | ||
| <AssemblyName>fsharplint</AssemblyName> |
There was a problem hiding this comment.
@webwarrior-ws maybe we should rather use ToolCommandName here, as instructed by #746 (comment)
There was a problem hiding this comment.
The comment that you've linked says that
It would have no impact on
dnx
webwarrior-ws
force-pushed
the
tool-name
branch
from
b4acb3e to
63419cd
Compare
|
I sent @duckmatt (previous/original maintainer) an email yesterday about the permissions to publish new versions in the old nuget package: https://www.nuget.org/packages/FSharpLint , but maybe he disagrees? Or any of you might disagree too, about breaking possible users of the old library that might upgrade and spend some time figuring out that they have to migrate to "FSharpLint.Core"? If that's the case, another solution (which is also much shorter) would be to reserve the name "fslint" which seems available and would result in a much more neat UX due to the super short command (thanks to dnx too): |
|
I think Fantomas did a change like that some time ago ('fantomas' was the library and 'fantomas-tool' was the tool, and now 'fantomas' is the tool and 'fantomas.core' is the library). The download stats at https://www.nuget.org/stats/packages/FSharpLint?groupby=Version do show several hundred downloads of 'fsharplint' in the last 6 weeks despite it not having been updated since 2016, so that might upset something so maybe 'fslint' is cleaner. |
|
Rebased to fix CI.
But can you review the docs changes, to make sure they really fix bug 746? Thanks @Numpsy |
|
I'll do a local build and try it (and dnx as well) |
|
I tried building this branch locally and installing/running it with the 'fsharplint' name and that appeared to work following the documentation. I did however have an instance of #687 when I tried running 
That worked after setting roll forward to latestMajor. That's not directly related to this change, but I'm not sure if it's something that might come up with dnx if that's just a .NET 10+ thing? |
That was fixed in #784 right? |
I reserved fslint some weeks ago so I guess we might go ahead with this. That said, I guess it's better to merge this breaking change when doing the 0.x -> 1.0 transition. |
webwarrior-ws
force-pushed
the
tool-name
branch
4 times, most recently
from
60de23c to
7241b8e
Compare
Hopefully so |
Change assembly name of FSharpLint.Console project from the (too long & convolutted) `dotnet-fsharplint` to the original `fsharplint`. This way it will be published as fsharplint nuget package and the tool name will be just fsharplint, not dotnet-fsharplint.
knocte
changed the title
As we haven't been able to get ahold of the original/previous maintainer to ask his opinion (and his permission) to override old nuget package named 'fsharplint', then we're switching to the even better and shorter "fslint" name. Closes fsprojects#746
It would be better to only change this (revert this commit) when releasing v1.0; otherwise this would point to the 0.0.1 fslint stub that does nothing.
3 participants
Change
FSharpLint.Consoleproject's assembly name, fromdotnet-fsharplinttofslint. This way it will be published asfslintnuget package and, combined withdnxinvocation (which this PR also highlights in the docs), will get UX much leaner.Closes #746