Before contributing | Scope | Theme code principles | Contributing code | Reporting a bug | Reviewing
We're really glad you're reading this, because we would love to have more developers contribute to this theme! If you're passionate about building for the next million entrepreneurs, you're in the right place.
If you encounter a bug or think of a useful feature for Dawn, please create a new issue. Creating an issue before jumping into code ensures we can discuss it and determine whether it aligns with the direction of the theme.
If you want to contribute to the theme, regardless of whether it's a small bug fix or correcting a typo, please feel free to do so. Any help goes a long way! Also, contributions aren't necessarily all code related. Other contributions can be in the form of issues, pull requests, discussions, etc.
This Github repository exists for the theme development community to discuss and solve problems directly related to Dawn. It is not the place to discuss general theme development problems, nor the place to seek help for non-Dawn related problems.
Shopify theme development is a big topic and it's completely normal that you will encounter problems which might require you to reach out for help. In fact, we provide several knowledge and support platforms for theme development already:
Before contributing to Dawn, please read the following theme code principles to better understand our fundamental approach to theme development. The expectation is that you follow these principles as you build for Dawn.
Browsers provide APIs to solve many problems: from WebGL and WASM-powered apps to static websites. The best APIs to use depends on the thing you’re building. Themes power ecommerce websites. In most cases, Web-native—making the most of the built-in features of browsers: HTTP, HTML, CSS, JavaScript, and the DOM—is a perfect fit for ecommerce websites. Ecommerce needs incredibly fast websites for mostly “logged out” traffic.
The most important principle.
Themes run on the evergreen Web. We leverage the latest web browsers to their fullest, while maintaining support for the older ones through progressive enhancement—not polyfills.
We write bespoke Web-native code with no abstractions. Frameworks, libraries, and dependencies don’t belong in our themes.
We engage with the browser ecosystem on behalf of our merchants to make Web-native ecommerce the best it can be.
“Don’t repeat yourself” is an anti-pattern. We do our utmost best to do more with less, but we don’t build abstractions around repetition. Instead, we use linting and testing to enforce consistently-good and up-to-date Web-native code.
The principle requirement.
Code must be lean, fast, and reliable. Our targets include:
- Zero Cumulative Layout Shift
- No DOM manipulation before user input
- No render-blocking JavaScript
- No long tasks
Functionality and design defaults to “no” until it meets this requirement. Code ships on quality.
We relentlessly and continuously optimize code within the constraint of being Web-native. If ever there is a feature that browsers have not made fast yet, we either don’t use it, or use it “as is” if it is fast enough. We trust that browsers will get faster over time.
Themes must be built with purpose. They shouldn’t support each and every feature in Shopify.
NoJS is our baseline.
We extract every bit of speed and functionality out of HTTP, semantic HTML, and CSS before writing our first line of JavaScript.
JavaScript can only be used to progressively enhance features. JavaScript cannot be required to find or purchase products. And the little JavaScript that we use must always fail gracefully, such that every browser gets the most “enhanced” experience that it can within the capabilities that it has.
ℹ️ We do so not because we expect buyers to experience our storefronts with JavaScript disabled, but because it keeps us aligned with the other principles: writing fast, server-rendered, Web-native code.
Our main constraint.
HTML must be rendered by Shopify servers using Liquid. Business logic and platform primitives such as translations and money formatting don’t belong on the client.
Server-rendered doesn’t imply “full page reload”. Async and on-demand rendering of parts of the page is OK, but we do it sparingly as a progressive enhancement.
No buyer is left behind.
The Web doesn’t require each page to be rendered pixel-perfect by each browser engine. Using semantic markup, progressive enhancement, and clever design, we ensure that themes remain functional regardless of the browser.
And since legacy browsers are often the slowest, we don’t burden them with polyfills. We rely instead on the fail-open nature of the Web to provide them with a “minimal but functional” experience.
You can follow these steps to go from setting up a store to creating a pull request for Dawn.
ℹ️ We'll assume you're already set up with Git and GitHub (if you're not familiar with these, start with these docs).
- Set up a development store so you can test your code changes (assuming you don't already have a store).
- Install the Shopify CLI by following these steps.
- Fork the repository, clone it and create a new branch:
git clone git@github.com:your-username/dawn.git
cd dawn
git checkout -b your-new-branch-name- Launch a development server:
shopify theme serve- Add your changes to the codebase.
- Commit your changes:
git commit -a -m="Your commit message"- Push your commit to your forked repository:
git push origin your-new-branch-name- Open a pull request. See GitHub's official documentation for more details.
- Before you can merge your pull request, you must sign Shopify's Contributor License Agreement (CLA).
Bugs are tracked as GitHub issues. Search open issues to see if someone else has reported a similar bug. If it's something new, open an issue. We'll use the issue to have a conversation about the problem you want to fix.
When creating a new issue, please ensure the issue is clear and include additional details to help maintainers reproduce it:
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible.
- Provide specific examples to demonstrate the steps. Include links to files, or copy/pasteable snippets. If you're providing snippets in the issue, use Markdown code blocks.
- Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
- Explain which behavior you expected to see instead and why.
- Include screenshots and animated GIFs where possible.
We (the Themes team) review every single PR. The purpose of reviews is to create the best version of Dawn we can for merchants, developers, and others who use it.
💛 Reviews are always respectful, acknowledging that everyone did the best possible job with the knowledge they had at the time. 💛 Reviews discuss content, not the person who created it. 💛 Reviews are constructive and start conversation around feedback.
You should always review your own PR first.
For code changes, make sure that you:
- Confirm that the changes meet our theme code principles.
- Check new or updated Liquid docs to confirm that the code used is up to date and isn't deprecated.
- If there are any failing checks in your PR, troubleshoot them until they're all passing.
- Add @Shopify/themes-front-end-developers as a reviewer.
When you open a pull request, you must fill out the "Ready for review" template before we can review your PR. This template helps reviewers understand your changes and the purpose of your pull request.
We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
As you update your PR and apply changes, mark each conversation as resolved.