Why did we stop maintaining this project? The project featured some nifty workflows which relied on certain libraries that became difficult to upgrade. In addition, Node updates rendered certain features inoperable and similarly required additional maintenance. Finally with the advent of better tools like Shopify CLI and Vite. Please read our suggested upgrade path towards modernizing.
This CLI provides development, build and deployment tasks for Shopify projects. The tool is designed to work with Wordpress projects too but currently it has not been tested properly with Wordpress. The tool enforces a Webpack-based development environment for bundling of styles and scripts.
After you install the new version run through the following steps:
- Remove the package-lock.json
- Add the following line to package.json under scripts:
"dependencies": "brrl-install"- run
npm run dependenciesThis will add dependencies that were originally managed in this package to your project's
package.json.
- Install
- Dependencies
- API
- Configuration Specifics
npm i @barrelny/cli -DIf you're using any plugins or transforms in your
postcss.configor.babelrc, please install these too. The CLI has an installations script accessible throughbrrl-installthat will, when executed, install the following packages for you:
- transform-object-rest-spread (babelrc)
- transform-object-assign (babelrc)
- postcss-import (postcss)
- postcss-inline-svg (postcss)
- postcss-color-function (postcss)
- autoprefixer (postcss)
- postcss-extend (postcss)
- precss (postcss)
This CLI tool requires the following components:
- A Shopify
config.yml(in the root directory or the<root>/distdirectory). This yml file needs to be formatted as per Shopify Theme Kit standards. Only include the following properties for each environment:
- theme_id
- store
- password
- api_key (needed for deployment)
- A
webpack.config.jsin your root directory. This file should at least export an object with the following properties:
module.exports = {
devtool: '',
entry: { main: ['main.css','main.js'] },
output: { ... },
module: { rules: [ ... ] }
}- For Shopify, a
<root>/srcdirectory with the following subdirectories:
src
|- assets
|- config
|-- lib
|- layout
|- locales
|- sections
|- templates
|-- customers
- A
package.jsonfile.
Here is an example of how to write your scripts for a Shopify project:
{
"scripts": {
"start": "brrl -w",
"build": "brrl -b",
"dependencies": "brrl-install",
"dev": "brrl -d -e development",
"staging": "brrl -d -e staging",
"production": "brrl -d -e production"
},
...
}Here is an example of how to write your scripts for a Wordpress project:
{
"scripts": {
"start": "brrl -w",
"build": "brrl -b",
"dependencies": "brrl-install"
},
...
}- .babelrc, .eslintrc and postcss.config.js files
EsLint should only use standard js rules except when incompatible with the project framework:
// .eslintrc
module.exports = {
"extends": ["standard"]
}- The following line in the entry JS file (e.g. main.js file):
__webpack_public_path__ = BRRL_PATH(BRRL_PUBLIC_PATH, BRRL_PROXY) // eslint-disable-line camelcase- A conditional in the main layout file to pull in the development assets if the watch task is active and the project is currently getting proxied by
localhost. For example, in a Shopify project, you can setup a pattern as follows:
In the head:
{% if settings.is_dev_mode %}
{{ '/dev/main.js' | script_tag }}
{% else %}
{{ 'main.css' | asset_url | stylesheet_tag }}
{% endif %}
In the foot:
{% unless settings.is_dev_mode %}
{{ 'main.js' | asset_url | script_tag }}
{% endunless %}There are 4 commands currently provided by this tool:
brrl-installbrrl -w or -watchbrrl -b or -buildbrrl -d or -deploy
This is an installation script that will add common packages that we develop with at Barrel into the project's package.json. You should run this command only once, when you are scaffolding out a project.
For each of the commands below, a -e <development|staging|production> variable can be flagged
This command creates a proxy environment for a Shopify or Wordpress site that uses Browsersync to provide hot module reloading. When CSS and JS assets are updated in your text editor, your browser will automatically reflect the changes. If you update a liquid file (or in Wordpress, a PHP file), the browser will automatically reload after the file as been copied to the /dist directory and uploaded to the Shopify theme outlined in the config.yml file. Note that JS and CSS files are compiled into memory and not written to the file system.
This command simply compiles your JS and CSS assets and, if it is a Shopify project, copies your theme assets in a /dist directory. The task will create separate minified JS and CSS assets.
This file is only suitable for Shopify projects. This task will not do anything if the project is not a Shopify project.
This command will build your project and deploy Only the necessary files to your Shopify theme. The deployment is based on a git diff workflow.
The person deploying can select at what point in the git repository they want to check for files that have changed. They can specify a tag, branch or commit hash, or “all” to deploy all files. This is done in the terminal window, in response to a prompt that is surfaced by the tool. If no answer is provided to the prompt, then the deployment script will check for files from the latest version tag (e.g. v1.0.1). If no version tag is found in the repo then it’ll check for files changed since the current branch was branched off of develop (or if the current branch is develop, branched off of master).
In this case, the deploying user should write "develop" in response to the console prompt. By putting in "develop", all files that have changed since the feature branch diverged from the develop branch will be deployed. This works when the targetted Shopify theme is up to date with the files on develop. If not, "all" can be written after the prompt instead to deploy all theme files.
In this case, the deploying user should write the last tag name, e.g. "v1.0.2" in response to the console prompt. This is effective if the deploying user is deploying version v1.0.3 to a theme that is already up to date with v1.0.2. By putting in "v1.0.3", the deployment task finds all files that have changed between versions and deploys only those files.
production:
theme_id: # This is the Shopify Theme ID
api_key: # This is the Shopify API Key for your Private App
password: # This is the Shopify API password for your Private App
store: # This is the *.myshopify.com URL (e.g barrel.myshopify.com)
staging:
theme_id: # This is the Shopify Theme ID
api_key: # This is the Shopify API Key for your Private App
password: # This is the Shopify API password for your Private App
store: # This is the *.myshopify.com URL (e.g barrel.myshopify.com)
development:
theme_id: # This is the Shopify Theme ID
api_key: # This is the Shopify API Key for your Private App
password: # This is the Shopify API password for your Private App
store: # This is the *.myshopify.com URL (e.g barrel.myshopify.com)
domain: # If Shopify has redirects to the primary domain enabled, put the domain here (e.g. barrelny.com)
local: # If you would like to use a local URL other than localhost, put it here (e.g. 10.0.1.8)
hmr: # If you would like to turn off hot module reloading, do so here (e.g. true or false)**
** I have found this useful when debugging on mobile devices. Sometimes HMR causes the device to reload unnecessarily.
MIT