dub icon indicating copy to clipboard operation
dub copied to clipboard

`dub lint` should only lint source files (excluding ignored ones)

Open WebFreak001 opened this issue 10 months ago • 7 comments

Currently dub lint simply calls dscanner in the package directory, this should be changed so that it calls D-Scanner for each source file, probably using an arguments/.rst file

Otherwise 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.

WebFreak001 avatar Sep 24 '23 12:09 WebFreak001

For example, dub lint ought not scan sources specified in excludedSourceFiles.

chances avatar Sep 24 '23 12:09 chances

Any update on this?

Imperatorn avatar Oct 24 '23 04:10 Imperatorn

I don't think any work has been started on this yet

WebFreak001 avatar Oct 24 '23 23:10 WebFreak001

Does dub even need to be linting?

maxhaton avatar Jan 02 '24 21:01 maxhaton

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 avatar Jan 02 '24 21:01 maxhaton

@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/vet
  • cargo 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 to package.json scripts: https://yarnpkg.com/configuration/manifest#scripts

PetarKirov avatar Jan 13 '24 23:01 PetarKirov

@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/vet
  • cargo 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 to package.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.

maxhaton avatar Jan 14 '24 14:01 maxhaton