What Shittier is#
Shittier is a TypeScript project published on GitHub by rohitdhas. The repository describes it as an “unconventional code formatting tool.” Its public metadata places it in the same broad category as code formatters and explicitly tags it with code-formatter, prettier, and shittier.
That tells us the useful part first: this is not presented as a security tool, a linter, a build system, or a framework. It is a formatter-shaped project. Its name and description suggest it is built around a different or deliberately odd take on formatting, likely in contrast to familiar tools such as Prettier. But the repository metadata alone does not support a stronger claim about its philosophy, supported languages, stability, or intended production role.
As of the collected repository data, Shittier had 1,767 stars, 30 forks, and 4 watchers. It is licensed under MIT. The repository language is TypeScript, and the last recorded push in the source metadata was on 2024-07-17.
Those numbers show visible public interest. They do not prove quality, safety, maintenance depth, or operational readiness. For developer tools, popularity is a weak signal. The actual question is narrower: does this tool solve a real formatting problem for your workflow, and can you tolerate the risk profile of adding it to your toolchain?
The concrete problem it may solve#
Code formatting tools exist to remove low-value argument from development. They turn style into a machine decision. That helps teams avoid endless diffs over spacing, wrapping, semicolons, quote style, and other local preferences.
Shittier appears to sit inside that formatter conversation. The repository description calls it “unconventional,” which matters. Most formatters sell consistency, predictability, and boring automation. An unconventional formatter may be useful for a different reason: testing assumptions, making formatting behavior intentionally visible, experimenting with style rules, or providing a sharper contrast to standard formatter defaults.
That can be useful in a few limited cases:
- A developer wants to inspect an alternative formatter model.
- A team wants to compare formatter behavior against familiar defaults.
- A tool author wants to study how a TypeScript formatter project is structured.
- A project wants a deliberately non-standard formatting step for experimentation.
The safe reading is still modest. The public metadata does not establish which languages or syntax forms Shittier handles. It does not establish whether it is compatible with a specific editor, CI setup, package manager flow, or monorepo structure. It also does not establish whether it aims to replace Prettier or simply comment on the formatter ecosystem through a working project.
That distinction matters. A formatter does not need to be malicious to create damage. If it rewrites code in unexpected ways, breaks syntax, causes noisy diffs, or behaves differently across environments, it can waste time and complicate review. Any formatter that touches source files should be evaluated as part of the development supply chain.
Who should care#
Developers and engineering leads should care if they are evaluating formatter behavior, building internal tooling, or tracking unusual open-source projects around developer workflow. Shittier is also relevant to people who watch the JavaScript and TypeScript tooling ecosystem, where small utilities can gain attention quickly when they challenge a common convention.
Security teams may have a narrower interest. A formatter is usually not a security product, but it can still enter sensitive paths. Developers may run it locally. CI may execute it on pull requests. Repositories may include it in package scripts. Editors may invoke it automatically. That means the trust question is real even when the tool itself is not security-focused.
The current source material does not support any claim that Shittier is unsafe. It also does not support the opposite claim. The right posture is verification before integration.
For individual experimentation, the risk is lower if the project is tested in a disposable branch or sample repository. For team use, the bar should be higher. A formatting tool can touch many files at once, and bad defaults can turn a simple trial into a large review problem.
What to verify before using it#
Before adding Shittier to a real project, check the repository directly. Do not rely only on stars or a short description.
Practical checks:
- Read the README and usage examples on the GitHub page.
- Confirm what file types and syntax it claims to support.
- Check install instructions and package provenance if it is distributed through a package registry.
- Review recent commits, open issues, and pull requests for maintenance signals.
- Look at the license terms. The repository metadata lists MIT, but teams should still verify the license file.
- Run it only on a test branch first.
- Compare diffs carefully before committing formatted output.
- Avoid wiring it into CI or editor auto-formatting until behavior is understood.
Teams should also decide what they are trying to learn. If the goal is stable formatting for production code, compare it against mature formatter requirements: determinism, language support, configuration behavior, editor integration, CI behavior, and failure modes. If the goal is experimentation, isolate it from production workflows and treat the output as test material.
What not to overclaim#
The public repository metadata gives only a limited picture. It supports saying that Shittier is a TypeScript-based, MIT-licensed, unconventional code formatting tool on GitHub with visible public attention. It does not support saying it is production-ready, widely adopted, secure, actively maintained beyond the observed push timestamp, or a drop-in replacement for any specific formatter.
It also does not support a security story by itself. There is no basis in the provided source material to claim exploit activity, vulnerability impact, malicious behavior, or defensive value. This is a developer-tool note, not an incident report.
That makes the useful conclusion simple. Shittier is worth a look if you care about formatter design or unconventional developer tooling. Treat it as code that may touch your code. Test first, inspect the repository, and keep it out of automated workflows until you know exactly what it changes.