Difference between revisions of "Lint"
m (added Category:Filesystems using HotCat) |
|||
| Line 8: | Line 8: | ||
find . -type l -! -exec test -e {} \; -print | find . -type l -! -exec test -e {} \; -print | ||
</source> | </source> | ||
| + | |||
| + | |||
| + | == Syntax checkers == | ||
| + | The verb 'lint' means to check some code for syntax violations. PHP has a built-in linter that you can invoke from the CLI with the <code>-l</code> switch. For the MediaWiki project, the full list of [[mw:Continuous_integration/Entry_points|Continuous Integration entry points]] describes the tools used in various circumstances. For instance, core uses [https://github.com/php-parallel-lint/PHP-Parallel-Lint php-parallel-lint] for checking PHP syntax. (See the [https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/composer.json#97 composer.json] file) | ||
| + | |||
| + | === Continuous Integration === | ||
| + | |||
| + | For continuous integration, you want to incorporate your linters into the source code repository as a commit hook. For example, in GitHub, this is referred to as "GitHub Actions". It can be important to make these available as repository hooks for another reason: forks and pull-requests can be done right in the web browser for sites like GitHub meaning you might be merging code that has never been through a true development environment or IDE. | ||
| + | |||
| + | GitHub has a marketplace product called "[https://github.com/marketplace/actions/super-linter Super Linter]" that basically will lint all the various languages and technologies you could want. | ||
| + | |||
| + | === Local Development === | ||
| + | |||
| + | To bring the warnings (or errors) closer to development, you want to make the tools available in your project as a 'Dev' dependency and setup commands that can be run with [[Composer]]. This way developers can use the tools to check their work '''before''' committing. | ||
{{References}} | {{References}} | ||
[[Category:Filesystems]] | [[Category:Filesystems]] | ||
| + | [[Category:MediaWiki]] | ||
| + | [[Category:Continuous Integration]] | ||
| + | [[Category:Tools]] | ||
Revision as of 20:33, 2 May 2023
Cleaning up your filesystem is as important as cleaning the lint out of the dryer screen[1].
Find symbolic links that are broken
find . -type l -! -exec test -e {} \; -print
Syntax checkers[edit | edit source]
The verb 'lint' means to check some code for syntax violations. PHP has a built-in linter that you can invoke from the CLI with the -l switch. For the MediaWiki project, the full list of Continuous Integration entry points describes the tools used in various circumstances. For instance, core uses php-parallel-lint for checking PHP syntax. (See the composer.json file)
Continuous Integration[edit | edit source]
For continuous integration, you want to incorporate your linters into the source code repository as a commit hook. For example, in GitHub, this is referred to as "GitHub Actions". It can be important to make these available as repository hooks for another reason: forks and pull-requests can be done right in the web browser for sites like GitHub meaning you might be merging code that has never been through a true development environment or IDE.
GitHub has a marketplace product called "Super Linter" that basically will lint all the various languages and technologies you could want.
Local Development[edit | edit source]
To bring the warnings (or errors) closer to development, you want to make the tools available in your project as a 'Dev' dependency and setup commands that can be run with Composer. This way developers can use the tools to check their work before committing.
References[edit source]
- ↑ Real lint from the dryer can be saved and used as an excellent fire-starter -- which is exactly why you also want to periodically clean it out of your ductwork!
