How to make first contribution to Phoenix project?

widianto · August 5, 2026, 2:22am

I think I’ve found a small improvement I could contribute to <%= web_namespace %>.CoreComponents (installer/templates/phx_web/components). I need a feature that isn’t available yet.

A noob question about contributing to Phoenix:

I’ve contributed to other open source projects before (translations and a few code changes), but this would be my first contribution to Phoenix.

Should I discuss the idea first before opening a pull request, or is it okay to submit one directly?
I searched the test suite but couldn’t find tests for core_components.ex template. Should I and where to include tests with the PR?

Thanks! Any advice or contribution guidelines would be greatly appreciated.

jswanner · August 5, 2026, 4:17am

From CONTRIBUTING.md:

Feature requests

Feature requests are welcome and should be discussed on the Phoenix subforum. But take a moment to find out whether your idea fits with the scope and aims of the project. It’s up to you to make a strong case to convince the community of the merits of this feature. Please provide as much detail and context as possible.

The generated code is tested by generating apps and running the generated tests, that said none of those test core components it seems

widianto · August 5, 2026, 8:15am

Thanks for your answer. It gave me some clues about where to look for more information.

rhcarvalho · August 5, 2026, 12:20pm

Describing the intention here would be a good next step

In general, the generated CoreComponents are meant as a starting point and only implement a minimal set of functionality.

The intention is that people do change that file in their own projects as the need arises. It demonstrates a pattern and how to work with HEEx, forms, etc.

github.com/phoenixframework/phoenix

installer%2Ftemplates%2Fphx_web%2Fcomponents%2Fcore_components.ex.eex

main


      
          At first glance, this module may seem daunting, but its goal is to provide
          core building blocks for your application, such as tables, forms, and
          inputs. The components consist mostly of markup and are well-documented
          with doc strings and declarative assigns. You may customize and style
          them in any way you want, based on your application growth and needs.

I’m saying that because my experience has been that the Phoenix team would be willing to accept bug fixes, but less likely to adopt say a completely custom new component.

widianto · August 5, 2026, 12:48pm

Thanks for your answer! I understand now why it should stay lean and minimal.

I originally thought supporting a class attribute by default would better showcase Phoenix’s flexibility.

Thanks for sharing your experience, it was really helpful.

LostKobrakai · August 5, 2026, 12:50pm

It’s also not some arbitrary minimal set, but meant to support just the markup used, generated or encountered by the phoenix generators.