contracts.ruby
vim-projectionist
contracts.ruby | vim-projectionist | |
---|---|---|
5 | 25 | |
1,439 | 1,040 | |
- | - | |
1.4 | 4.6 | |
about 1 year ago | 3 months ago | |
Ruby | Vim Script | |
BSD 2-clause "Simplified" License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
contracts.ruby
-
A few words on Ruby's type annotations state
I had written a code contracts library for Ruby about 10 years ago [1]. I stopped working on it, mainly because it only provided runtime type checking, and I wanted static type checking. Nowadays my main language is typescript. I miss ruby, but can't give up the static typing that typescript provides. I really wish Ruby had a type system with the same level of support. VSCode has phenomenal TS support, and there's a community adding types to projects [2]. This is something I'd like for Ruby also.
> An integral part of this informality is relying on Matz’s taste and intuition for everything that affects the language’s core.
I think a more defined process would mean a better future for Ruby and Ruby developers.
- [1] https://github.com/egonschiele/contracts.ruby
- [2] https://github.com/DefinitelyTyped/DefinitelyTyped
-
Why I Stopped Using Sorbet in All My Ruby Projects
Contracts gem can be a nice middle-ground. It has a fairly readably syntax and only checks method inputs and outputs at runtime. We use it to annotate important core methods, while leaving the rest type-free.
-
Should gems support old Ruby versions like 2.4?
For example contracts gem needs to have a separate version/branch for ruby 3.x due to the breaking change above
-
Cells - Introduction
This gives me access to input values as long as I defined them via attr_reader. Oh what's the Contract XXX above attr_reader? They are from contracts.ruby and completely optional and won't be explained in this post. You can safely ignore those and maybe study that gem later.
vim-projectionist
-
What plugins do you use to manage work across multiple files?
Tim Pope's projectionist for navigating to files of a particular category or to related files from the current one: https://github.com/tpope/vim-projectionist.
-
A few words on Ruby's type annotations state
> For myself, I'm fine with the typing being in a separate .rbs file
We type[0] by having one separate .rbs file per .rb file. Works really well with an editor's vertical splits: type outline on one side, code on the other. That, or use something like vim-projectionist[1].
[0]: (WIP: there's a huge codebase to type, but we're progressively getting there) https://github.com/DataDog/dd-trace-rb/tree/master/sig
[1]: https://github.com/tpope/vim-projectionist
-
What's the coolest thing you've done with Neovim?
One of the originals I guess must be tim pope's https://github.com/tpope/vim-projectionist
- Could use some advice for managing projects in a way that fits my mental model and codebase. Monolithic codebase with project files spread around different working directories. Or just help me change my mental model.
-
Project & File navigation
use https://github.com/tpope/vim-projectionist - define the relationships between files (example: app/*js are 'source' files and test/*js are 'test' files). Projectionist sets up `:A` to jump to the 'alternate' file (jump between a 'source' file and its 'test' for instance), and `:Esource` and `:Etest` commands to find/navigate by the kind of file. This is very powerful IMO - for projects with good structure I can quickly jump between related test/source/model/blah files very quickly using these commands. For projects without good structure I rethink or get the team to talk about how we might improve the project organization (ie, lack of structure is a code smell!)
-
New Plugin: telescope-alternate
I love Tpope’s https://github.com/tpope/vim-projectionist but this one seems like a great replacement 😎
-
JVM language users- how do you write your test files?
Tim Pope's excellent Projectionist plug-in has an alternate file feature, which makes it very easy to switch between test and implementation files.
-
other.nvim - open alternative files for the current buffer.
The plugin is inspired by vim-projectionist and https://github.com/vim-scripts/a.vim
-
vim-projectionist isn't autoloading in Vim
This feels like a bug, since the plugin doesn't behave as expected when following the installation section verbatim. I filed a bug here: https://github.com/tpope/vim-projectionist/issues/168
-
Auto-open unit test file
You need https://github.com/tpope/vim-projectionist. Gotta have a file structure for unit tests though.
What are some alternatives?
Fundamental Ruby - :books: Fundamental programming with ruby examples and references. It covers threads, SOLID principles, design patterns, data structures, algorithms. Books for reading. Repo for website https://github.com/khusnetdinov/betterdocs
jumpwire.nvim - Jump easily between related files.
fast-ruby - :dash: Writing Fast Ruby :heart_eyes: -- Collect Common Ruby idioms.
denite.nvim - :dragon: Dark powered asynchronous unite all interfaces for Neovim/Vim8
Ruby style guide - A community-driven Ruby coding style guide
autojump - A cd command that learns - easily navigate directories from the command line
Rails style guide - A community-driven Ruby on Rails style guide
vim-rails - rails.vim: Ruby on Rails power tools
Best-Ruby - Ruby Tricks, Idiomatic Ruby, Refactoring and Best Practices
bufexplorer - BufExplorer Plugin for Vim
RSpec style guide - RSpec Best Practices
fzf.vim - fzf :heart: vim