Open WebFreak001 opened 1 year ago
For example, dub lint
ought not scan sources specified in excludedSourceFiles
.
Any update on this?
I don't think any work has been started on this yet
Does dub even need to be linting?
dub is already too complicated, surely this could go entirely, surely?
I can't think of a time when I've wanted my package manager to lint
@maxhaton most language ecosystems I've interacted with in recent years, what you would typically call package manager has evolved into a task runner and/or even a simple build system (like dub). While one may argue that having this functionality built into Dub is scope creep, to answer your point directly:
I can't think of a time when I've wanted my package manager to lint
A few examples:
go vet
: https://pkg.go.dev/cmd/vetcargo clippy
https://doc.rust-lang.org/stable/clippy/usage.htmlnpm lint
/ yarn lint:all
scripts for your project.I'd be in favor of removing dub lint
if we could over a drop in replacement in a form similar to package.json
scripts
: https://yarnpkg.com/configuration/manifest#scripts
@maxhaton most language ecosystems I've interacted with in recent years, what you would typically call package manager has evolved into a task runner and/or even a simple build system (like dub). While one may argue that having this functionality built into Dub is scope creep, to answer your point directly:
I can't think of a time when I've wanted my package manager to lint
A few examples:
go vet
: https://pkg.go.dev/cmd/vetcargo clippy
https://doc.rust-lang.org/stable/clippy/usage.html- In the Node.js ecosystem it's typical to define
npm lint
/yarn lint:all
scripts for your project.I'd be in favor of removing
dub lint
if we could over a drop in replacement in a form similar topackage.json
scripts
: https://yarnpkg.com/configuration/manifest#scripts
Fair enough although that doesn't quite match my point about desire — i.e. I personally have never reached for anything like this, and I'm usually pretty wary of off-the-peg linting in general because it can take a bit of fiddling to get things where you want, and by the time you've done that you could've done it yourself from scratch (e.g. you might only want to lint code that directly relates to a git commit etc etc)
Anyway, scripts would be good in that dub as a codebase suffers from using way too much abstraction to implement relatively concrete tasks, so maybe it can be the generic thing it always wanted to be.
As it stands I just can't see the complexity paying for itself.
In the short term though I think cutting down would be good, and also probably not trying to enforce too many defaults e.g. dub profile builds seem like a nice idea except that they only really expose the built in profiling DMD can expose (IIRC) which is deeply flawed, so people get tripped up all the time.
Similarly unittests. Having a universal entry to tests is a good scaling but win it should explicitly just be some kind of task runner as you say.
Currently
dub lint
simply callsdscanner
in the package directory, this should be changed so that it calls D-Scanner for each source file, probably using an arguments/.rst fileOtherwise it will instruct D-Scanner to scan also temporary files such as the .d files that are emitted by some build tools as temporary files.