David Anson

Updated: markdownlint-cli2-action #Markdown #linting #GitHub #Action to v21

- Update markdownlint version (markdownlint-cli2 v0.19.0, markdownlint v0.39.0).

github.com/marketplace/...

Updated: markdownlint-cli2 v0.19.0, #Markdown #linting CLI for #NodeJS

- Add `--format` parameter for editor integration
- Update output formatters for severity `warning`
- Explicitly version Docker containers for `pre-commit`
- Update dependencies

github.com/DavidAnson/m...

Fair point, though I think it glosses over something significant: error rate. Reputable newspapers (or blogs like your own!) publish retractions when they get a fact wrong. But that’s a rare event. LLMs hallucinate by design and that’s a common event. The “trustability level” is wildly different.

Not so easy if you want them to preserve tab stops, perhaps. :)

Updated: markdownlint v0.39.0, #Markdown #linting library for #NodeJS

- Add MD060/table-column-style
- Improve MD001/MD007/MD009/MD010/MD029/MD033/MD037/MD059
- Add support for reporting violations as warnings
- Deprecate resultVersion and toString (breaking change)

github.com/DavidAnson/m...

Interesting! In the meantime, I had realized a simple way to improve this with just a tiny bit of CSS. I made a note to look at that when I get a chance.

I remembered why I didn’t do that in the first place! Old posts are fully HTML vs. newer posts which are Markdown and pass code blocks through a highlighter during render. There’s no render step for old posts to give an opportunity to reformat those samples. And static edits wouldn’t be theme-aware.

Context: dlaa.me/blog/post/81...

Sorry! Older posts use hard-coded HTML for light theme. That shouldn’t be the case with newer posts which use highlight.js. For example: dlaa.me/blog/post/ic...

I’ve made myself a note to see if it’s safe to remove the formatting from old stuff and let the auto-highlight code handle colorizing.

Eww, sorry.

Only Administrators members should be able to write there, so it seems like they run their service as Admin OR they relax privileges. Both are anti-patterns, I think.

Are you getting Beetlejuice vibes? Because I’m getting Beetlejuice vibes.

How did you convince the police officer that your bike was yours? Being able to unlock your lock should not have been enough. You could’ve added that to a legitimately-locked bike right before you contacted the officer.

Wow, looks like *someone* woke up on the Smurf side of bed!

Can’t imagine why…

Updated: markdownlint #VSCode #Markdown #linting extension to v0.60.0

- Updated `markdownlint` dependency to `0.38.0`
- Add `MD059`/`descriptive-link-text`
- Improve `MD025`/`MD027`/`MD036`/`MD038`/`MD041`/`MD043`/`MD045`/`MD051`/`MD052`

marketplace.visualstudio.com/items?itemNa...

Am I wrong to worry they’ll botch the upcoming remake?

Updated: markdownlint-cli v0.45.0, #Markdown #linting CLI for #NodeJS

- Update `markdownlint` to `0.38.0`
- Add `MD059`/`descriptive-link-text`
- Improve `MD025`/`MD027`/`MD036`/`MD038`/`MD041`/`MD043`/`MD045`/`MD051`/`MD052`
- Remove support for EOL Node 18

github.com/igorshubovyc...

Updated: markdownlint-cli2-action #Markdown #linting #GitHub #Action to v20

- Update markdownlint version (markdownlint-cli2 v0.18.1, markdownlint v0.38.0)

github.com/marketplace/...

GitHub - DavidAnson/markdownlint-cli2: A fast, flexible, configuration-based command-line interface for linting Markdown/CommonMark files with the markdownlint library A fast, flexible, configuration-based command-line interface for linting Markdown/CommonMark files with the markdownlint library - DavidAnson/markdownlint-cli2

Updated: markdownlint-cli2 v0.18.0, #Markdown #linting CLI for #NodeJS

- Use user ID in Docker containers for security
- Update dependencies (including markdownlint)
- Remove support for end-of-life Node 18

github.com/DavidAnson/m...

GitHub - DavidAnson/markdownlint: A Node.js style checker and lint tool for Markdown/CommonMark files. A Node.js style checker and lint tool for Markdown/CommonMark files. - DavidAnson/markdownlint

Updated: markdownlint v0.38.0, #Markdown #linting library for #NodeJS

- Add MD059/descriptive-link-text
- Improve MD025/MD027/MD036/MD038/MD041/MD043/MD045/MD051/MD052
- `markdown-it` parser no longer a dependency (breaking change)
- Remove support for EOL Node 18

github.com/DavidAnson/m...

Thank you for your kindness!!

Yep, I’m 100% with you on simplicity being key!

Bro, I *always* got my mind on my money and my money on my mind. ;)

I’ll stop after this reply because I don’t want to be arguing just for the sake of it. :)

But regarding reputation, I’ve been in the npm ecosystem for maybe a decade now and there are a literal handful of developers whose stuff I will use unconditionally. Everything and everyone else is a mystery.

Unpopular doesn’t mean bad, though. Perhaps by design, this approach risks discouraging or preventing the creation of niche packages for a small community. Some of the joys of OSS may disappear once people are forced to focus on money.

But maybe that’s the only solution to the problem at hand…

It doesn’t have to be as extreme as my examples to be imbalanced. As an alternative, consider what “npm fund“ does: as a project owner, I get a listing of all transitive dependencies looking for funding. I end up paying exactly the set of projects I’m benefiting from and not just the top level ones.

Agree!

No easy answers here, but thought it might be useful to share with you. I hope this is helpful and doesn’t just seem like complaining.

Thanks again for all that you do!

Conversely, if I have an unpopular package that uses 100 popular packages, I have to run a massive deficit every month while they cash in? Neither seems equitable.