nomicode / wip-lintfree Goto Github PK

See:

• https://www.conventionalcommits.org/en/v1.0.0/
• https://github.com/conventional-changelog/commitlint
• https://cbea.ms/git-commit/
• https://jorisroovers.com/gitlint/
• https://github.com/conventional-changelog/conventional-changelog
• https://github.com/conventional-changelog/releaser-tools
• https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-recommended-bump
• https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-cli
• https://github.com/semantic-release/release-notes-generator

Tutorials:

• https://www.mokkapps.de/blog/how-to-automatically-generate-a-helpful-changelog-from-your-git-commit-messages/

Additional work:

• Go through this project's history and edit every commit to turn it into a conventional commit
• Then regenerate changelog, even if it disagrees with our tags (in fact, recreate tags, even if they disagree with our package uploads)

Would be nice if I could find something that integrates well with VS Code.

See:

• https://www.npmjs.com/package/husky

See:

• https://www.npmjs.com/package/lint-staged

The run command should read config files from a separate directory and should allow the user to wrap other tools and pre-process their output (especially satisfying the use-case of enriching the output by adding line number information). This would help with some tools (like Prettier, Black, and Lychee) which fall into two categories:

• They either reformat the code and present success or fail status (in which case, line number information can be gleaned by comparing the before and after results)
• They produce per-file errors but provide no line number information (in which case, line number information can be gleaned by grepping the file for strings that match the error output)

In fact, it seems to me that these two categories could be generalized so that a single built-in feature could be configured to handle most use-cases.

The run command could also take care of other common tasks:

• Identifying a list of files or directories to search (based on file patterns, media types, or more advanced methods, such as inspecting the first line of the file for a specific directive)
• Passing the list of files to the tool in question (either as a list of arguments, or, perhaps preferably, running the tool in parallel, one file at a time)

This issue was inspired by:

• #53

At the moment, the way I a using Obelist is as follows:

• Create a parser configuration like .obelist/ec.yaml
• Create a script like test/lint/ec.sh, which is responsible for selecting which files to lint, then runs ec on each file and pipes the results into the obelist command
• Add rules to the Makefile to wrap the lint script

This situation is even more complex for tools like Prettier, which requires me to wrap the tool, produce diffs, and generate line-based annotations before piping to the obelist command.

I don't want to set up all this machinery on every project. It would be much easier if Obelist could automate all of this for me.

My current thinking is:

• Extend the configuration files so that you can specify:

  • Which files to lint
  • What command to use to lint them
  • How to parse the results

  The configuration could include information about how to wrap the results (e.g., for commands that only produce diffs).

• Create a new subcommand: obelist run that takes the name of a single lint check and is capable of running the lint commands and parsing the output in one step (avoiding the need to write a separate shell script to wrap the lint command)

• Add a central .obelist.yaml file, allowing you to configure a default set of lint checks (avoiding the need to integrate multiple lint checks into a separate build system such as GNU Make)

https://github.com/click-contrib/click-configfile

See:

• https://github.com/pyinstaller/pyinstaller
• https://github.com/pyenv/pyenv/wiki#suggested-build-environment (bottom of page)

https://github.com/click-contrib/click-man

Some ideas:

• console
• github
• gcc
• json
• checkstyle

Some ideas:

• Plugins that add commands to the CLI script
• Plugins that add syntax support
• Plugins that provide wrapper functionality

• How do various editors and IDEs handle this (e.g., VS Code, BBEdit)?
• How do GitHub annotations handle this?

Based on the outcome of this research, what is the best way forward when no line number can be determined?

See:

• https://docs.sourcery.ai/IDEs/VSCode/
• https://docs.sourcery.ai/Command-Line-Interface/

https://www.schemastore.org/json/

https://github.com/schemastore/schemastore/

• shellharden
  • ShellCheck will do just fine for this
• shfmt (closed by #57)
• whitespace (went with https://github.com/dlenski/wtf)

https://github.com/click-contrib/click-didyoumean

turn the scripts I'm making to wrap other tools into a shippable package

perhaps made as plugins with octonote as an extendable package

or perhaps as a seperate package that can wrap tools and produce standard output

same is true for standardized scripts that run all lint tools

https://github.com/bottle-garden/octonote/security/code-scanning

https://click.palletsprojects.com/en/7.x/bashcomplete/

https://github.com/redhat-developer/vscode-yaml

See:

• https://www.conventionalcommits.org/en/v1.0.0/

https://click-log.readthedocs.io/en/stable/

I would like a project name that is:

• Less tied to GitHub specifically (perhaps this project could be useful for other Git platforms)
• Perhaps is a bit less focused on the "note" aspect and incorporate the wrapping of lint tools to produce more useful action as well as the wrapping of lint tools for the purpose of output through the tool

Plus there are a few other projects on GitHub already with this name

https://github.com/click-contrib/sphinx-click

I want to be able to reuse my customizations

https://github.com/marketplace/actions/changelog-validate

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore(deps): update dependency prospector to v1.10.3
• fix(deps): update dependency urlextract to v1.9.0
• chore(deps): update actions/checkout action to v4
• chore(deps): update dependency flake8 to v7
• fix(deps): update dependency lxml to v5
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update dependency click to v8.1.7
• fix(deps): update dependency lxml to v4.9.4
• fix(deps): update dependency pyyaml to v6.0.1
• chore(deps): update dependency reorder-python-imports to v3.13.0
• chore(deps): update dependency vulture to v2.11
• fix(deps): update dependency natsort to v8.4.0
• fix(deps): update dependency wrapt to v1.16.0
• chore(deps): update dependency ipython to v8
• fix(deps): update dependency charset-normalizer to v3
• fix(deps): update dependency sh to v2
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

See:

• https://lgtm.com/projects/g/nomiro/obelist/rev/pr-b18f0ba89096fe9f49893b89742211c4613fa540

At the moment, I can generate line-based annotations from tools that produce diff-based output. This approach is clumsy, and I don't want to re-implement this multiple times in multiple repositories.

Problems:

• Some tools will only modify files in place. These tools need to be wrapped so that a temporary copy of the file is created, modified, and then compared to the original. Other tools can print diffs without modifying the files. Both types of tools need to be accommodated.

• Some tools can only be used on one file at a time. Other tools can be run on multiple files at once. Both types of tools need to be accommodated.

Possible approaches:

• A new subcommand that genericizes the job of a wrapper script (i.e., handles copying files, producing diffs, and so on) and can be used with any third-party tool.

• A new diff parser that reads in a diff (or diffs) and produces a set of line-based annotations.

• Extend the parser configuration for tools like this so that you can specify the command to run, how the diffs should be generated, and so on. Then, instead of running the lint command with a wrapper and passing the results to obelist parse. You could do something like obelist run and have the end-to-end process handled for you.

I accidentally left a binary file in the source repository and while running a lint check, the EditorConfig check produced a Python error when trying to process the output.

To solve this problem, I filtered out binary files from the EditorConfig checks. However, the underlying issue should be replicated and investigated.