> Finally, I have been thinking about how to encourage spell checking within code. I think a better solution would be a terminal command (like Standard) where a user just can run:
Interesting timing since I've been polishing up my source code spell checker in prep for announcing it. I even used the name "typos" because I couldn't find it in use as a CLI.
Even in my own work I know my comments, and inline strings, often contain typos. It would be nice to have a dedicated tool for catching new additions in pull-requests, etc.
One thing I miss when using VSCode is the lack of spell checking compared to Sublime or even Vim.
I think a CLI might be nice, but even then typos in code aren't such a big deal IMO. Sometimes they do come up with copy in UI code, but even then, NBD.
So for me, a spell checker in CI sounds like a nice to have, not a necessity.
Maybe it was just me but at my last role, I worked on a piece of software with a typo that stuck out like a sore thumb but the cost was too high to ever fix it (impacted multiple products with independent schedules or were just being milked and had no staffing).
I also remember some bike shedding over a person using a British spelling for a word instead of the American. Some times linters are just nice for deciding minutia so people don't argue (see also formatters).
However, I fully admit, compared to a lot of other priorities in software, these are minor.
Yeah, had a similar problem on a previous project. A typo in a config file, which was then leaked to an API which was then leaked to multiple clients of that API.
Eventually we fixed it in our API gateway for the API we provide to customers because it looked unprofessional, so we have a mapping layer in that API that exists purely to correct the typo.
I'm on mobile just now, so I can't give you the link or even the name right now, but there is a good spell checker extension available. I use it on Windows, but presume it works elsewhere too. IIRC, it was a little fiddly to setup (think I had to download spell check files separately), but it's been plain sailing after that.
I mainly use JetBrains Rider though, and that has really good spell checking support built-in. Something I really like about Rider's support is that, just like lining rules, you have the option of saving additional words at the "Team Shared" level, so the whole team can use the same extra dictionary words. The same function works in Visual Studio with ReSharper installed, and presumably it's available in all JetBrains IntelliJ-based IDEs.
I also enable & use it with languages it doesn't really have proper support for (like sql and ruby) - just add words to the dictionary as they come up.
I came here to recommend the same.
This has saved me from sooo many silly mistakes.
English is not my first language, or that of many of my colleagues, so it's very easy for spelling mistakes to slip into the code.
And very hard to correct after it's part of the codebase...
The main annoyance is that the dictionary is directly inline in your main json config file. It's around 50% of mine right now. I wish there was a way to refer to an external file.
Mike, it took you a lot of courage to make this decision. You deserve respect for making a hard decision and being public about it for the benefit of others.
I’m so moved (and admittedly conflicted!) that my writing helped you come to this decision. I’m grateful you were able to identify the issue around permission, and also grieving with you about the loss. (Closing down a business or project is a valid form of grief. We don’t often name it as such, but that sadness is real and it is grief.)
It sounds like you learned a lot and will carry that with you to your next projects. Wishing you all the best. I hope you stay in touch and continue sharing what you learn from users, encouraging and otherwise!
The conclusion is the key takeaway. If you're finding spelling errors post-commit, it is too late to be directly actionable. Automatically-generated pull requests are just layering on more complications without addressing the core reality: If you can run a linter locally, before you commit, it is trivial to fix the problems where they stand.
The same goes for many things that might be part of your CI pipeline today.
Yeah this seems like something better as a pre commit check, or as a run on save, the same way I might run go lint or gofmt, not after the code is in the repo but as I’m saving. The “not talking to the users” mistake can be super fatal in products like this.
I'd phrase it slightly differently. We can and should fix things in response to CI failures. The problem is more so the cost/value trade off for developers. The lower the perceived value is, the more good will that will be lost with developers for having to do another iteration to fix them. Integrating these into the developers workflow as early as possible, like rustfmt or gofmt, lowers the cost and developers are less likely to have a problem with it.
At this point, the main value of having something in CI is either for the reviewers to give them a sense of things, like coverage or to help enforce people are using those tools, which means it should ail CI.
I don't really follow this. Ideally, the spelling errors should fail the build and ordinarily I wouldn't expect PRs to be able to be merged with failing CI checks.
Presumably it's possible to suppress false positive typo reports too and flesh out a per-project dictionary to help all other developers?
That is just fucking annoying for no benefit. Don't send me a "CI failed" email and make me click down into 4 different deep levels of pages to find out it failed because of a typo.
Real text customers see lives in various i18n tools and you know what, they can tell you about typos as you make them!
As someone whose spelling is generally subpar having continuous spelling checking in my editor is great.
Best would be if it's integrated with a Language Server Protocol. For instance it would be nice to flag misspelled variable, function, and class names. And only flag them where they are defined. And not flag variable names in comments.
I'd say the way to do it is to have a --check option which fails if things are misspelled. That can be run in CI to catch problems, and leaves the developer to fix it in their own way (pre commit hook/IDE integration/command line tool/ability to spell).
> I reached the 100 user threshold in about a month, then it took GitHub over 6 months to allow me to start charging for usage.
That sort of delay can kill a new product's momentum. I wonder if this is consistent with what others have seen or if it's something unique to this project?
I had similarly negative experiences with the GitHub app marketplace. They wouldn't even let me list my app as an unverified listing! That's the lower tier which supposedly had no minimum user count but didn't allow payments.
My app was nonsensically rejected for not having enough users yet. Isn't the whole point of the marketplace to help obtain users? When I replied to appeal (directly quoting the no-minimum-user-count statement), I never received a response, and none of the ~dozen GitHub employees I know were either willing or able to help me.
I gave up on the marketplace and just wrote my own Stripe billing, but after two years my app still only barely breaks even on its infrastructure costs. I deeply regret wasting my time building a GitHub app.
Adding insult to injury: my GitHub app is a SaaS CI version of my open source CLI tool, which GitHub internally uses as a core infrastructure component for their DB schema management. 8 months after my GitHub app's launch, GitHub open sourced some Actions code which uses my open source CLI tool to substantially duplicate the purpose of my SaaS app, albeit in a less compelling way (their approach doesn't provide inline annotations, is much slower to execute, and involves contorting the CLI in unintended ways).
Now I keep getting support requests from random users who want help configuring GitHub's action, but don't want to consider ever paying for a simpler-to-install solution with more features. It's extremely demotivating.
> I wonder if this is consistent with what others have seen or if it's something unique to this project?
I've spoken to a few other GitHub app creators, it's a fairly common experience. I think GitHub Actions are kind of viewed as the preferred alternative by GitHub so that's what they're focusing on.
My 2 cents: I run Reviewable (https://reviewable.io), a reasonably successful app for GitHub. It precedes Marketplace so I handle billing directly with Stripe, but when Marketplace recently reduced their fees to 5% I looked into migrating there. The lack of developer control over subscriptions and the painfully long turnaround times with support to get some straightforward questions answered (3+ months!) convinced me that they're not serious about it. Anecdotally, I also heard that the discoverability boost from being listed on Marketplace isn't that big either.
Based on my research I wouldn't recommend using GitHub Marketplace in its current state.
This seems like the challenge with things like github marketplace. Devs rarely hold the purse strings. Managers can't be bothered with the minutia. Indie devs that do care about such things, well, already either spell well or have spell check in their editors.
So there seems to be limited utility for github to even have a marketplace. Enterprisey all in one solutions seem to be the only thing that can succeed there.
Sad to hear it didn't work out, but I'm sure there were a few lessons learned. Seems like the Github marketplace is not great to launch and iterate fast. Maybe try the Slack marketplace for the next micro product?
GitHub’s ecosystem bears all the hallmarks of a platform that management decided was going to compete with Amazon and Google in just a few short years. Everything half baked and seems to exist just for the pure purpose of being able to say it exists.
For me, it’s been the enterprise security features that for the most part aren’t covered by the API, and have decidedly limited docs. Very frustrating.
I'd love a GitHub Action that (unofficially) integrates Grammarly with GitHub checks. Just like the unofficial VS Code extension: https://github.com/znck/grammarly#grammarly
Sounds like a smart decision and, while it sucks to have things not work out, I’m sure the author will do more cool stuff down the line.
For everyone interested in “small SaaS” (for the lack of the better term), I really recommend listening to the “Software Social” podcast, co-hosted by Michelle Hansen, mentioned in the article: https://mjwhansen.com/software-social-podcast/
I love the social software podcast! It feels like I'm listening to real people building products, plus following along with Colleen Schnettler build her product has been really inspirational :D
> I really feel that GitHub isn’t interested in having 3rd Party Apps promoted on their platform
I don't know if this is just a coincidence with Microsoft now owning GitHub, but this has historically been a Microsoft trait. So little third party software exists for Microsoft tooling because there's the fear that as soon as they see it they'll just do a first party version. (Recent example: https://www.thurrott.com/windows/windows-10/235783/appget-cr...)
The direction GitHub has been moving for the last many months is very sad. It's amazing how fast a company can alienate developers, and apparently, also small projects wanting to bring some value for both parties.
I can only assume that they now only focus on targeting corporations -- faithful to classic MS style.
38 comments
[ 0.24 ms ] story [ 61.8 ms ] threadInteresting timing since I've been polishing up my source code spell checker in prep for announcing it. I even used the name "typos" because I couldn't find it in use as a CLI.
https://github.com/crate-ci/typos
There are also some other code spell checkers out there: https://github.com/crate-ci/typos/blob/master/docs/compariso...
End result was a minor update to git to fix a couple of typoes:
https://blog.steve.fi/i_m_a_bit_of_a_git__hacker__.html
Even in my own work I know my comments, and inline strings, often contain typos. It would be nice to have a dedicated tool for catching new additions in pull-requests, etc.
I think a CLI might be nice, but even then typos in code aren't such a big deal IMO. Sometimes they do come up with copy in UI code, but even then, NBD.
So for me, a spell checker in CI sounds like a nice to have, not a necessity.
Maybe it was just me but at my last role, I worked on a piece of software with a typo that stuck out like a sore thumb but the cost was too high to ever fix it (impacted multiple products with independent schedules or were just being milked and had no staffing).
I also remember some bike shedding over a person using a British spelling for a word instead of the American. Some times linters are just nice for deciding minutia so people don't argue (see also formatters).
However, I fully admit, compared to a lot of other priorities in software, these are minor.
Eventually we fixed it in our API gateway for the API we provide to customers because it looked unprofessional, so we have a mapping layer in that API that exists purely to correct the typo.
I mainly use JetBrains Rider though, and that has really good spell checking support built-in. Something I really like about Rider's support is that, just like lining rules, you have the option of saving additional words at the "Team Shared" level, so the whole team can use the same extra dictionary words. The same function works in Visual Studio with ReSharper installed, and presumably it's available in all JetBrains IntelliJ-based IDEs.
I also enable & use it with languages it doesn't really have proper support for (like sql and ruby) - just add words to the dictionary as they come up.
I’m so moved (and admittedly conflicted!) that my writing helped you come to this decision. I’m grateful you were able to identify the issue around permission, and also grieving with you about the loss. (Closing down a business or project is a valid form of grief. We don’t often name it as such, but that sadness is real and it is grief.)
It sounds like you learned a lot and will carry that with you to your next projects. Wishing you all the best. I hope you stay in touch and continue sharing what you learn from users, encouraging and otherwise!
The same goes for many things that might be part of your CI pipeline today.
At this point, the main value of having something in CI is either for the reviewers to give them a sense of things, like coverage or to help enforce people are using those tools, which means it should ail CI.
Presumably it's possible to suppress false positive typo reports too and flesh out a per-project dictionary to help all other developers?
Real text customers see lives in various i18n tools and you know what, they can tell you about typos as you make them!
And while nice, the inspections often catch other more important code issues.
These are also generally highlighted with an indicator of some sort to catch as you’re working on the code.
Are pre-commit inspections / visual indicators not generally a part of most dev workflows?
I would think spelling would be a part of the most basic text editor / ide at this point.
Best would be if it's integrated with a Language Server Protocol. For instance it would be nice to flag misspelled variable, function, and class names. And only flag them where they are defined. And not flag variable names in comments.
That sort of delay can kill a new product's momentum. I wonder if this is consistent with what others have seen or if it's something unique to this project?
My app was nonsensically rejected for not having enough users yet. Isn't the whole point of the marketplace to help obtain users? When I replied to appeal (directly quoting the no-minimum-user-count statement), I never received a response, and none of the ~dozen GitHub employees I know were either willing or able to help me.
I gave up on the marketplace and just wrote my own Stripe billing, but after two years my app still only barely breaks even on its infrastructure costs. I deeply regret wasting my time building a GitHub app.
Adding insult to injury: my GitHub app is a SaaS CI version of my open source CLI tool, which GitHub internally uses as a core infrastructure component for their DB schema management. 8 months after my GitHub app's launch, GitHub open sourced some Actions code which uses my open source CLI tool to substantially duplicate the purpose of my SaaS app, albeit in a less compelling way (their approach doesn't provide inline annotations, is much slower to execute, and involves contorting the CLI in unintended ways).
Now I keep getting support requests from random users who want help configuring GitHub's action, but don't want to consider ever paying for a simpler-to-install solution with more features. It's extremely demotivating.
I've spoken to a few other GitHub app creators, it's a fairly common experience. I think GitHub Actions are kind of viewed as the preferred alternative by GitHub so that's what they're focusing on.
Based on my research I wouldn't recommend using GitHub Marketplace in its current state.
So there seems to be limited utility for github to even have a marketplace. Enterprisey all in one solutions seem to be the only thing that can succeed there.
There is an unofficial SDK for TypeScript (maybe other languages too) so this shouldn't even be too hard: https://github.com/stewartmcgown/grammarly-api#unofficial-gr...
For everyone interested in “small SaaS” (for the lack of the better term), I really recommend listening to the “Software Social” podcast, co-hosted by Michelle Hansen, mentioned in the article: https://mjwhansen.com/software-social-podcast/
I don't know if this is just a coincidence with Microsoft now owning GitHub, but this has historically been a Microsoft trait. So little third party software exists for Microsoft tooling because there's the fear that as soon as they see it they'll just do a first party version. (Recent example: https://www.thurrott.com/windows/windows-10/235783/appget-cr...)
https://github.com/codespell-project/codespell
More listed in the check-all-the-things English section:
https://github.com/collab-qa/check-all-the-things/blob/maste...
I can only assume that they now only focus on targeting corporations -- faithful to classic MS style.