@syncify/cli 0.2.4-beta → 1.0.0-alpha.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (40) hide show
  1. package/LICENSE +10 -6
  2. package/dist/index.d.cts +1815 -0
  3. package/dist/index.d.ts +1815 -0
  4. package/package.json +101 -101
  5. package/pnpm-lock.yaml +16526 -4200
  6. package/readme.md +77 -2017
  7. package/scripts/hot.js.liquid +25 -0
  8. package/dist/api.js +0 -16
  9. package/dist/cjs.js +0 -221
  10. package/dist/cli.js +0 -12
  11. package/dist/index.js +0 -18
  12. package/hot.js.liquid +0 -3
  13. package/schema/syncify.config.json +0 -676
  14. package/schema/syncify.env.json +0 -58
  15. package/schema/syncify.package.json +0 -11
  16. package/types/api.d.ts +0 -319
  17. package/types/cli.d.ts +0 -541
  18. package/types/config/index.d.ts +0 -530
  19. package/types/config/terser.d.ts +0 -267
  20. package/types/config/views.d.ts +0 -234
  21. package/types/index.d.ts +0 -55
  22. package/types/internal/cache.d.ts +0 -97
  23. package/types/internal/commands.d.ts +0 -396
  24. package/types/internal/errors.d.ts +0 -101
  25. package/types/internal/file.d.ts +0 -285
  26. package/types/internal/filters.d.ts +0 -81
  27. package/types/internal/hot.d.ts +0 -161
  28. package/types/internal/index.d.ts +0 -513
  29. package/types/internal/markdown.d.ts +0 -104
  30. package/types/internal/plugin.d.ts +0 -127
  31. package/types/internal/processors.d.ts +0 -54
  32. package/types/internal/reports.d.ts +0 -123
  33. package/types/internal/requests.d.ts +0 -288
  34. package/types/internal/shared.d.ts +0 -124
  35. package/types/modules/html-minifier-terser.d.ts +0 -211
  36. package/types/transforms/image.d.ts +0 -15
  37. package/types/transforms/json.d.ts +0 -42
  38. package/types/transforms/script.d.ts +0 -308
  39. package/types/transforms/style.d.ts +0 -219
  40. package/types/transforms/svg.d.ts +0 -189
package/readme.md CHANGED
@@ -1,2092 +1,152 @@
1
- **BETA VERSION**
2
-
3
- <hr>
4
-
5
- # SYNCIFY
6
-
7
- A lightening fast, extensible and superior alternative Shopify CLI (Theme Development) tool. Syncify provides developers with a powerful CLI and employs an intuitive approach for creating Shopify themes.
1
+ <br>
2
+ <p align="center">
3
+ <a href="https://syncify.sh">
4
+ <img src="https://raw.githubusercontent.com/panoply/syncify/3b7839da26b4355943c94ddf93f81e2f41a6a2bf/assets/logo-text.svg"
5
+ width="270px">
6
+ </a>
7
+ </p>
8
+ <h1></h1>
8
9
 
9
- ### Demos
10
+ Syncify is a specialized tool designed for Shopify theme development. It offers an array of features that significantly enhance productivity, integration and workflow on the Shopify platform. Originally created to address the in-house mediocrity of OSS (theme dev) offerings from the Shopify team, Syncify exits as the superior alternative delivering an overall better, more flexible, and more powerful approach to webshop development.
10
11
 
11
- - [Syncify Dawn Basic](https://github.com/panoply/syncify-dawn-basic)
12
- - [Syncify Dawn Advanced](https://github.com/panoply/syncify-dawn-advanced)
12
+ Documentation: **[https://syncify.sh](https://syncify.sh)**
13
13
 
14
- ### Key Features
14
+ ### Examples / Themes
15
15
 
16
- - Watch, upload, download and export to multiple storefronts and themes.
17
- - Intelligent path mapping capabilities for custom directory structures.
18
- - HOT reloading of assets, section, snippets, templates and layouts.
19
- - Clear, concise, informative and beautiful CLI logging.
20
- - An elegant global directory based metafields sync approach using JSON files.
21
- - Digests and spawns existing build tools for asset transformations.
22
- - Prompt based CLI/TUI and exposed module API for script usage.
23
- - Pull, push and merge support for aligning local and remote sources.
24
- - Supports additional resources like Files, Pages and Redirects.
16
+ The **[Syncify Straps](https://github.com/SyncifyCLI)** github organization provides a collection of usage examples and starting point themes using Syncify. You can use the command line to generate new projects with the available straps. Refer to readme of each strap in the repositories.
25
17
 
26
- ### Why?
18
+ ### Editor Intergration
27
19
 
28
- I have been working on the Shopify platform for several years and nothing the Shopify team have produced has actually increased my productivity. Despite the advancements Shopify has made in recent years I still find that their developer tooling to be rather average. The Shopify CLI is cool and all but for theme development it fails to achieve fluidity.
20
+ For an integrated development experience in your text editor, please consider using the **[VSCode Liquid](https://github.com/panoply/vscode-liquid)** extension which has built-in support for Syncify. VSCode Liquid exists as a superior alternative to the Shopify backed extension and is maintained and created by the same author of Syncify.
29
21
 
30
- Syncify is how I believe theme creation, development and maintenance should be handled. It's fast, flexible, extensible, scalable and will not lock you into some restrictive low grade elementary workflow. It allows you to progressively enhance your development process and produce the most efficient and performant results with the tools you already love.
22
+ ### Getting Help?
31
23
 
32
- # Install
24
+ Join the **[Shopify Developers Discord](https://discord.gg/shopify-developers-597504637167468564)** and ask your questions in the **`# syncify`** channel under the **`projects`** tab. Connect with other developers, maintainers, and contributors already using Syncify in their projects or within their agency.
33
25
 
34
- Syncify is distributed as both an ESM and CJS module. It is recommended that you install as a development dependency in your project opposed to installing globally.
26
+ # Installation
35
27
 
36
- **PNPM**
28
+ You can install Syncify as a development dependency or globally. There are a couple of different versions available, all of which can be consumed via the NPM Registry. Please consider using [pnpm](https://pnpm.js.org/en/cli/install) as your package manager for a faster and better experience with Syncify and NodeJS development.
37
29
 
38
- ```bash
39
- pnpm add @syncify/cli -D
40
- ```
30
+ More information at: **[syncify.sh/releases](https://syncify.sh/releases)**
41
31
 
42
- > Use `pnpx @syncify/cli` for remote execution
32
+ ### Stable Release
43
33
 
44
- **NPM**
34
+ The most stable and latest version of Syncify is available for consumption on the [NPM Registry](https://www.npmjs.com/package/@syncify/cli).
45
35
 
46
36
  ```bash
47
- npm i @syncify/cli --save-dev
37
+ pnpm add @syncify/cli@latest -g
48
38
  ```
49
39
 
50
- > Use `npx @syncify/cli` for remote execution
40
+ ### Nightly Release
51
41
 
52
- **Yarn**
42
+ The nightly releases of Syncify can be installed on the `@next` version via NPM Registry and available within [next](https://github.com/panoply/syncify/tree/next) branch.
53
43
 
54
44
  ```bash
55
- yarn add @syncify/cli --dev
45
+ pnpm add @syncify/cli@next -g
56
46
  ```
57
47
 
58
- # Overview
59
-
60
- The main purpose of Syncify is to facilitate seamless theme development between your local machine and Shopify store/s. It ships with build, watch, download, upload, merge and pull capabilities for interfacing with remote Shopify webshop's. Together with a prompt based execution model, Syncify provides developers with theme control that aims to exceed expectations.
61
-
62
- ### Theme Files
48
+ ### Global Installations
63
49
 
64
- Syncify uses built-in capabilities when handling snippets, templates, layouts, locales, configs and sections. Files using a `.liquid` or `.json` extension are typically considered theme files in syncify and always determined before handling. Content transformations like minification and path mappings are applied to these files types either natively or with plugins.
50
+ Global installations of Syncify make the CLI binary available system-wide and are the preferred approach. Syncify will regularly check for version updates and notify you when new ones are available. If you're using a `syncify.config.js` (or `.ts`) configuration file for individual projects, install the [@syncify/config](/packages/config/) package to access the `defineConfig` helper utility.
65
51
 
66
- ### Data Files
52
+ If you opt for a global installation of the nightly release builds, be aware that there might be breaking changes, and version checks occur more frequently, potentially leading to slower runtimes. For more details on how Syncify manages version control and publishing, please refer to the [releases](https://syncify.sh/releases) documentation.
67
53
 
68
- Syncify exposes and introduces an elegant low-level method for interfacing with shop metafields, pages, redirects and files. Pull, push, merge and delete resource capabilities are provided for data identified files and for metafield resources a directory/file path based approach is employed which allows developers to advance their workflows in a controlled and extensible manner.
69
-
70
- ### Asset Files
71
-
72
- Syncify does not want to re-create or impede on developer preferences and tool appropriation. Build tools and bundlers specifically designed for processing different asset types can be spawned and run in parallel with Syncify's `build` and `watch` instances, but for more advanced use cases, Syncify also provides developers with pre-processor capabilities via [transforms](#transform). Transform can be leveraged for processing TypeScript, JavaScript, CSS, SCSS and SVG file types by exposing integrated configuration wrappers around popular and performant modules like ESBuild, SASS Dart, SVGO Tailwind and more!
54
+ # Contributing
73
55
 
74
- # Setup
56
+ Contributions are welcome and appreciate! This project is a monorepo managed with [pnpm](https://pnpm.js.org/), which handles dependency and workspace management. Dependencies follow the [workspace protocol](https://pnpm.io/workspaces#workspace-protocol-workspace), ensuring a symlinked structure with pnpm managing NPM registry versions.
75
57
 
76
- After installing you will need to configure a connection to your shopify store. Syncify requires you provide either an Admin API Access Token (recommended) or API Key and Secret as credentials.
58
+ The [packages](/packages/) directory contains modules consumed by the core [syncify](/syncify/) module. To contribute bug fixes or enhancements, you’ll need to fork or clone the entire project, as there are no plans to introduce and expose packages as separate sub-modules. Development is designed for use with [VS Code](https://code.visualstudio.com/), and maintaining consistency within this setup is encouraged.
77
59
 
78
60
  <details>
79
61
  <summary>
80
- <strong>Authorize</strong>
62
+ Pre-requisites
81
63
  </summary>
82
64
  <p>
83
65
 
84
- You will need to create a [private app](https://help.shopify.com/en/manual/apps/private-apps) to obtain this information from Shopify. If you are coming from [Theme Kit](https://shopify.dev/themes/tools/theme-kit) you might be able to port those settings but it is recommended that you generate API access information specifically for usage with Syncify.
85
-
86
- > There are plans to provide an official Syncify Shopify App to make this easier in future releases.
87
-
88
- **Steps:**
89
-
90
- 1. From your Shopify admin, go to **Apps**.
91
- 2. Click **Develop apps**.
92
- 3. Click **Create an app**.
93
- 4. Provide an App name (eg: `Syncify`) and click **Create app**
94
- 5. The app will be created, then click **Configure Admin API Scope**
95
- 6. Select the required scopes (listed below)
96
- 7. Click **Save**
97
- 8. Goto the **API credentials** tab,
98
- 9. Under **Access Tokens** press the **Install app** button.
99
- 10. Press **Reveal token once** and copy the token into an `.env` file.
66
+ - [Git](https://git-scm.com/)
67
+ - [Node v20^](https://nodejs.org/)
68
+ - [Pnpm v9^](https://pnpm.js.org/)
69
+ - [VSCode](https://code.visualstudio.com/)
100
70
 
101
71
  </p>
102
72
  </details>
103
73
 
104
74
  <details>
105
75
  <summary>
106
- <strong>Scopes</strong>
76
+ Third Parties (optional)
107
77
  </summary>
108
- <p>
109
-
110
- You need to provide Syncify read and write access to a couple of admin endpoints so it can perform operations. Below are the required scopes you will need to enable within in your private app.
111
-
112
- #### Files
113
-
114
- - write_files
115
- - read_files
116
-
117
- #### Pages
118
-
119
- - write_online_store_pages
120
- - read_online_store_pages
121
-
122
- #### Themes
123
-
124
- - write_themes
125
- - read_themes
126
-
127
- </p>
128
- </details>
129
-
130
- # Credentials
131
-
132
- Shop credentials can be stored within a `.env` or `.env.syncify.json` file. You can also provide credentials at runtime using `process.env` variables. The preferred approach is to store this information within a `.env` file.
133
-
134
- ### Using a `.env` file
135
-
136
- When using a `.env` file, you can provide shop credentials in either uppercase of lowercase format. The `.env` values **must** begin with the shop name following an underscore `_` character. If you are syncing to multiple storefronts just follow the pattern for each store.
137
-
138
- Using an **API Access Token**
139
-
140
- ```env
141
- YOUR-SHOP-NAME_API_TOKEN = 'shpat_abcdefghijklmnopqrstuvwz'
142
- ```
143
-
144
- Using an **API key** and **API Secret**
145
-
146
- ```env
147
- YOUR-SHOP-NAME_API_KEY = 'abcdefghijklmnopqrstuvwz'
148
- YOUR-SHOP-NAME_API_SECRET = 'abcdefghijklmnopqrstuvwz'
149
- ```
150
-
151
- ### Using `process.env` variables
152
-
153
- Syncify also supports runtime credential assignment. This approach allows you to set credentials via the command line or within a script executable. This is highly discouraged and rather insecure.
154
-
155
- Using an **API Access Token**
156
-
157
- ```js
158
- // Using an API Access Token
159
- process.env['YOUR-SHOP-NAME_API_TOKEN'] = 'shpat_abcdefghijklmnopqrstuvwz';
160
- ```
161
-
162
- Using an **API key** and **API Secret**
163
-
164
- ```js
165
- // Using an API Key and API Secret
166
- process.env['YOUR-SHOP-NAME_API_KEY'] = 'abcdefghijklmnopqrstuvwz';
167
- process.env['YOUR-SHOP-NAME_API_SECRET'] = 'abcdefghijklmnopqrstuvwz';
168
- ```
169
-
170
- # Configuration
171
-
172
- Syncify supports `syncify.config.js` and `package.json` configurations. Depending on your preference, either option suffices and no restrictions are imposed. If you are defining options within your projects `package.json` file you can assign options on the `syncify` property.
173
-
174
- ### Supported Files
175
-
176
- - `syncify.config.ts`
177
- - `syncify.config.js`
178
- - `syncify.config.ts`
179
- - `syncify.config.mjs`
180
- - `syncify.config.cjs`
181
- - `syncify.config.json`
182
-
183
- ### Default Options
184
-
185
- This is defaults used in a `syncify.config.js` file. Options commented out within [transforms](#transform), [processors](#processors) and [minify](#minify) require peer dependencies to be installed to be used.
186
-
187
- <!-- prettier-ignore -->
188
- ```ts
189
- import { defineConfig } from '@syncify/syncify';
190
-
191
- export default defineConfig({
192
- input: 'source',
193
- output: 'theme',
194
- export: 'export',
195
- import: 'import',
196
- config: '.',
197
- clean: true,
198
- stores: [
199
- {
200
- domain: '',
201
- themes: {}
202
- }
203
- ],
204
- hot: {
205
- label: 'visible',
206
- history: true,
207
- method: 'hot',
208
- inject: true,
209
- scroll: 'preserved',
210
- server: 3000,
211
- socket: 8089,
212
- layouts: [
213
- 'theme.liquid'
214
- ],
215
- },
216
- logger: {
217
- clear: true,
218
- silent: false,
219
- stats: true,
220
- warnings: true
221
- },
222
- paths: {
223
- redirects: 'redirects.yaml',
224
- assets: 'assets/**/*',
225
- files: 'files/**/*',
226
- config: 'config/*.json',
227
- locales: 'locales/*.json',
228
- layout: 'layouts/*.liquid',
229
- sections: 'sections/*.liquid',
230
- snippets: 'snippets/*.liquid',
231
- metafields: 'metafields/**/*.json',
232
- customers: [
233
- 'templates/customers/*.json',
234
- 'templates/customers/*.liquid'
235
- ],
236
- pages: [
237
- 'pages/*.md',
238
- 'pages/*.html'
239
- ],
240
- templates: [
241
- 'templates/*.json',
242
- 'templates/*.liquid'
243
- ],
244
- },
245
- spawn: {
246
- build: {},
247
- watch: {},
248
- },
249
- views: {
250
- snippets: {
251
- prefixDir: false,
252
- separator: '-',
253
- global: []
254
- },
255
- sections: {
256
- prefixDir: false,
257
- separator: '-',
258
- global: []
259
- },
260
- pages: {
261
- suffixDir: true,
262
- author: '',
263
- global: [],
264
- language: [
265
- 'html',
266
- 'markdown'
267
- ],
268
- }
269
- },
270
- transforms: {
271
- script: {},
272
- style: {},
273
- svg: {}
274
- },
275
- processors: {
276
- json: {
277
- crlf: false,
278
- indent: 2,
279
- useTab: false,
280
- exclude: []
281
- },
282
- // esbuild: {},
283
- // sass: {},
284
- // postcss: [],
285
- // tailwind: {},
286
- // svgo: {},
287
- // sprite: {},
288
- // sharp: {},
289
- },
290
- terser: {
291
- json: {
292
- assets: true,
293
- config: true,
294
- locales: true,
295
- metafields: true,
296
- templates: true,
297
- exclude: []
298
- },
299
- views: {
300
- collapseWhitespace: true,
301
- minifySchema: true,
302
- minifyScript: true,
303
- minifyStyle: true,
304
- removeComments: true,
305
- stripDashes: true,
306
- exclude: []
307
- },
308
- // script: {},
309
- // style: {},
310
- }
311
- });
312
- ```
313
-
314
- # Getting Started
315
-
316
- It is relatively easy to get started developing Shopify themes using Syncify. If you are converting an existing project and using Theme Kit or another build environment you can progressively adapt it into your workflow by manually configuring how Syncify should behave. Whatever the case, have a look at the [Syncify Strap](https://github.com/panoply/syncify-strap) repository.
317
-
318
- ### Pre-requisites
319
-
320
- Before going over the features Syncify provides, it is assumed that you have done the following:
321
-
322
- 1. Installed Syncify as a development Dependency
323
- 2. Created a private app and added API credentials
324
- 3. Added a `syncify.config.ts` file in the root of your project
325
-
326
- ### Contents
327
-
328
- - [Directories](#directories)
329
- - [Paths](#dirs)
330
- - [Stores](#stores-required)
331
- - [Hot](#hot)
332
- - [Spawn](#spawn)
333
- - [Views](#views)
334
- - [Transforms](#views)
335
- - [Processors](#views)
336
- - [Terser](#views)
337
-
338
- ## Directories
339
-
340
- In Syncify you define custom base directories for your theme files. The values you define refer to a directory name which is relative to the root of your project. You **cannot** define multi-level directories (eg: `some/dir`) or reverse paths (eg: `../dir`).
341
-
342
- <!-- prettier-ignore -->
343
- <table>
344
- <thead>
345
- <tr>
346
- <th width="500px">API</th>
347
- <th width="500px">CLI</th>
348
- </tr>
349
- </thead>
350
- <tbody>
351
- <tr>
352
- <td>
353
-
354
- <!-- prettier-ignore -->
355
- ```json
356
- {
357
- "input": "source",
358
- "output": "theme",
359
- "import": "import",
360
- "export": "export",
361
- "config": "."
362
- }
363
- ```
364
78
 
365
- </td>
366
- <td height="200px">
367
-
368
- <!-- prettier-ignore -->
369
- ```bash
370
- --input -i # source
371
- --output -o # theme
372
- --config -c # config
373
- --export -e # config
374
- ```
375
-
376
- </td>
377
- </tr>
378
-
379
- </tbody>
380
- </table>
381
-
382
- ### Input > Output
383
-
384
- Syncify expects projects to have an **input** directory path which contains theme **source** files. Files contained within an input directory are written to your defined **output** directory path. The generated output will be reflective of your online store and in most cases you will add the output directory to your `.gitignore` file because it can always be rebuilt from input.
385
-
386
- If you are used to working from a single directory (e.g: Dawn) then it is important that you understand the difference between the **input** and **output** directories.
387
-
388
- # Stores (Required)
389
-
390
- The `stores` option accepts an **object** or **array** type. Each item will hold a _settings_ object that contains references to your shopify store/s and their theme/s. For each store you define, Syncify requires you provide the shop name and theme id/s you wish to sync. The `themes` object uses a **key** > **value** structure.
391
-
392
- > Please see theme [commands](#commands) example for more information on how this is used with the CLI.
393
-
394
- ### CLI
395
-
396
- ```bash
397
- --theme, -t <target> # theme targeting
398
- ```
399
-
400
- ### API
401
-
402
- ```ts
403
- import { defineConfig } from '@syncify/cli';
404
-
405
- export default defineConfig({
406
- stores: [
407
- {
408
- domain: 'shop-1', // equivalent of shop-1.myshopify.com
409
- themes: {
410
- dev: 123456789,
411
- prod: 123456789,
412
- stage: 123456789,
413
- test: 123456789
414
- }
415
- }
416
- ]
417
- });
418
- ```
419
-
420
- <details>
421
- <summary>
422
- <strong><code>Domain</code></strong>
423
- </summary>
424
79
  <p>
425
80
 
426
- The `domain` option expects a string value, which is your Shopify store name without the `myshopify.com` portion. The domain will be used by the CLI as a target argument. Each store (domain) can have multiple themes.
427
-
428
- </p>
429
- </details>
430
-
431
- <details>
432
- <summary>
433
- <strong><code>Themes</code></strong>
434
- </summary>
435
- <p>
81
+ - [Potion Theme](https://marketplace.visualstudio.com/items?itemName=sissel.material-potion)
82
+ - [Github Desktop](https://desktop.github.com/)
83
+ - [iTerm2](https://iterm2.com/)
436
84
 
437
- The `themes` option refers to theme ids the store contains. This option is an object type which uses **key** > **value** mappings. The theme **keys** represent a unique target name, this can be any alpha numeric value. The **key** value is used by the CLI as target reference. The **value** should be the theme id.
85
+ > _While not required, if you wish to recreate the environment in which this project is developed then you can install and leverage the above additional third-party tooling._
438
86
 
439
87
  </p>
440
88
  </details>
441
89
 
442
- # Metafields
443
-
444
- ###### NOT YET AVAILABLE
90
+ ## Installation
445
91
 
446
- The `metafields` directory `path` reference is where you can provide **global** JSON metafield files that can be synced to your Shopify store. Metafield sync capabilities provided by Syncify use a simple **directory** > **file** based approach. The sub-directory names represent a metafield `namespace` value and JSON file names contained within represent metafield `key` values.
92
+ - Ensure [pnpm](https://pnpm.js.org/) is installed globally `npm i pnpm -g`
93
+ - Leverage `pnpm env` if you need to align node versions
94
+ - Clone this repository `git clone https://github.com/panoply/syncify.git`
95
+ - Run `pnpm i` in the root directory
447
96
 
448
- > Syncify will keep your remote and local metafield references aligned with one another and warn you when local versions do not match remote versions. This will help prevent you from overwriting changes that may have been applied by third-party apps or online within your store.
97
+ The project will be complied and all containing workspace packages will build during the `postinstall` operation.
449
98
 
450
- **Pull Metafields**
99
+ ## Developing
451
100
 
452
- Syncify provides you with simple interactive prompt based approach for importing pre-existing metafields from your online store. You can optionally choose which metafields you'd like to maintain. Use the `-m` or `--metafields` flag together with the `--pull` flag on the command line to download metafields:
101
+ All packages are compiled with [ESBuild](https://esbuild.github.io/) via [tsup](https://tsup.egoist.sh/#usage). You can `cd` into any package or alternatively you can run `pnpm dev` from workspace root to begin development on the core logic which lives in the [/syncify](/syncify) directory. Projects contained the [/packages](/packages/) directory are consumed by the core package (i.e, `@syncify/cli`) and are also available in isolated via the NPM Registry.
453
102
 
454
- ```
455
- $ syncify --metafields --pull
456
- ```
457
-
458
- **Merge Metafields**
459
-
460
- Working with metafields from your local machine may have result in unexpected overwrites if changes were made to remote versions that conflict with local versions. In order to combat this Syncify support **merge** capabilities which can be used to merge changes when metafield modification timestamps differ. Use the `-m` or `--metafields` flag together with the `--merge` flag on the command line perform local and remote alignments.
103
+ #### Per Package
461
104
 
462
105
  ```
463
- $ syncify --metafields --merge
106
+ pnpm dev Watch and build modes
107
+ pnpm build Build mode only (production)
464
108
  ```
465
109
 
466
- **Structure**
467
-
468
- In order to best illustrate how the metafield sync capabilities work it is important that you understand the structure logic. The directory based approach and naming conventions employed are imperative and strict. Syncify wants to prevent irreversible overwrites or deletions from occurring, so please be mindful and wary when using this feature.
469
-
470
- <table>
471
- <thead>
472
- <tr>
473
- <th align="left" width="300px">&nbsp;&nbsp;&nbsp;&nbsp;Metafield Structure</th>
474
- <th align="left" width="700px">&nbsp;&nbsp;&nbsp;&nbsp;Description</th>
475
- </tr>
476
- </thead>
477
- <tbody>
478
- <td>
479
- <pre>
480
- <code>
481
- source
482
-
483
- └── metafields
484
-
485
- ├── garment
486
- │ ├── fits.json
487
- │ ├── sizes.json
488
- │ └── fabrics.json ㅤㅤ ㅤㅤ ㅤㅤ
489
-
490
- └── details
491
- ├── colors.json
492
- └── weight.json
493
- </code>
494
- </pre>
495
- </td>
496
- <td>
497
- &nbsp;&nbsp;&nbsp;Metafields will be published to the global <code>shop</code> object.<br>
498
- &nbsp;&nbsp;&nbsp;Syncify will use the sub-directory names as the metafield<br>
499
- &nbsp;&nbsp;&nbsp;<code>namespace</code> and the JSON file names contained within<br>
500
- &nbsp;&nbsp;&nbsp;each namespace directory are used as the metafield <code>key</code> name.<br><br>
501
- <strong>Example:</strong><br><br>
502
- <ul>
503
- <li><code>{{ shop.metafields.garment.fits.value }}</code></li>
504
- <li><code>{{ shop.metafields.garment.sizes.value }}</code></li>
505
- <li><code>{{ shop.metafields.garment.fabrics.value }}</code></li>
506
- <li><code>{{ shop.metafields.details.colors.value }}</code></li>
507
- <li><code>{{ shop.metafields.details.weight.value }}</code></li>
508
- </ul>
509
- </td>
510
- </tr>
511
- </tbody>
512
- </table>
513
-
514
- ### Options
515
-
516
- <details>
517
- <summary>
518
- <strong><code>Input</code></strong>
519
- </summary>
520
- <p>
521
-
522
- The `input` option refers to your projects **src** location This is the directory where your development theme files exist. Syncify defaults this directory to `source`. The value defined here will be prepended to any path you define within `paths`.
523
-
524
- </p>
525
- </details>
526
-
527
- <details>
528
- <summary>
529
- <strong><code>Output</code></strong>
530
- </summary>
531
- <p>
532
-
533
- The `output` option refers to your project **dist** location. This is the directory where transformed theme files from `input` will be written. Syncify defaults this to `theme`. The `output` directory will be reflective of your online shop. You should point any asset files executing via spawned processes to the `assets` directory contained within this location.
534
-
535
- </p>
536
- </details>
537
-
538
- <details>
539
- <summary>
540
- <strong><code>Config</code></strong>
541
- </summary>
542
- <p>
543
-
544
- The `config` option refers to a directory within your project where configuration files exist, like (for example) a `rollup.config.js` or `webpack.config.js` file. Syncify by default (when this option is **undefined**) will look for config files in the root of your project but this might not always be ideal as it can create clutter in the workspace. The `config` directory allows you to optionally place spawned config files within a sub-directory and informs Syncify to look for these files from that location.
545
-
546
- > Typically this is directory is named `scripts` in node projects.
110
+ > Almost all packages will expose the above commands via `package.json` script, with some exceptions depending on module. The `pnpm build` command however is available within all modules.
547
111
 
548
- </p>
549
- </details>
550
-
551
- <details>
552
- <summary>
553
- <strong><code>Import</code></strong>
554
- </summary>
555
- <p>
556
-
557
- The `import` option refers to a directory where downloaded themes will be written. Syncify provides the ability to download themes from your online store and it is within this directory the files are created.
558
-
559
- </p>
560
- </details>
561
-
562
- <details>
563
- <summary>
564
- <strong><code>Export</code></strong>
565
- </summary>
566
- <p>
567
-
568
- The `export` option refers to a directory where packaged (`.zip`) themes will be written when running the `package` command. Packaged themes will be prepended with the version number defined in the projects `package.json` file.
569
-
570
- </p>
571
- </details>
572
-
573
- <details>
574
- <summary>
575
- <strong><code>Metafields</code></strong>
576
- </summary>
577
- <p>
578
-
579
- The `metafields` option refers to a directory within your project which can contain global JSON metafield files. The path location you reference here should point to a directory of sub-directories. Please refer to the [Metafields](#metafields) section for more information.
580
-
581
- **Correct**
112
+ #### Recursive (Workspace Root)
582
113
 
583
114
  ```
584
- {
585
- "dirs": {
586
- "metafields": "source/metafields"
587
- }
588
- }
115
+ pnpm build Build production bundles for all modules and packages
589
116
  ```
590
117
 
591
- **Invalid**
118
+ #### Targeting (Workspace Root)
592
119
 
593
120
  ```
594
- {
595
- "dirs": {
596
- "metafields": "source/metafields/**/*.json"
597
- }
598
- }
599
- ```
600
-
601
- </p>
602
- </details>
603
-
604
- # Paths
605
-
606
- The `paths` option allows you to define a custom set of path locations which point to theme specific files contained within the defined `input` directory. Syncify does not require you set a development structure consistent with that required by Shopify and you should begin to decouple from that logic as it is generally a flawed and borderline daft approach. The contents (files) contained within your **input** will be re-routed as a standard theme structure that Shopify understands when generating **output** distribution.
607
-
608
- Each path option accepts either a `string` or `string[]` array list of glob [anymatch](https://www.npmjs.com/package/anymatch) patterns. Paths will automatically resolve to the `input` directory, so you do not need to include it within your configurations.
609
-
610
- ### API
611
-
612
- By default, Syncify assumes you are using the basic-bitch (default) structure as follows:
613
-
614
- <!-- prettier-ignore -->
615
- ```ts
616
- import { defineConfig } from '@syncify/syncify';
617
-
618
- export default defineConfig({
619
- input: 'source',
620
- output: 'theme',
621
- paths: {
622
- assets: 'assets/**',
623
- config: 'config/*.json',
624
- locales: 'locales/*.json',
625
- layout: 'layout/.liquid',
626
- metafields: 'metafields/**/*.json',
627
- sections: 'sections/*.liquid',
628
- snippets: 'snippets/*.liquid',
629
- templates: 'templates/*.liquid',
630
- customers: 'templates/customers/*',
631
- // pages: 'pages/*',
632
- // redirects: 'redirects.yaml',
633
- }
634
- })
121
+ pnpm @acquire <dev|build> Targets the acquire config bundle
122
+ pnpm @kill <dev|build> Targets the process kill package
123
+ pnpm @update <dev|build> Targets the version check utility
124
+ pnpm @uws <dev|build> Targets the uWebsockets repackage
125
+ pnpm @hot <dev|build> Targets the HOT Reloading client
126
+ pnpm @turndown <dev|build> Targets the reversed markdown parser
127
+ pnpm @json <dev|build> Targets the JSON parser and differ
128
+ pnpm @timer <dev|build> Targets the timing utility
129
+ pnpm @ansi <dev|build> Targets the CLI enhancement package
635
130
  ```
636
131
 
637
- ### Custom Structures
638
-
639
- Below are **2** different **input** structures and an **output** structure. The **default structure** is what Syncify will use (as above) if no `paths` have been defined in your configuration, the tool defaults to this. The **customized structure** is an example of how you _could_ arrange an `input` directory using the Syncify `paths` option. The **output structure** is what Syncify will generated as an **output** which Shopify can digest.
640
-
641
- <table>
642
- <thead>
643
- <tr>
644
- <th width=330px>Default Structure</th>
645
- <th width="330px">Customized Structure</th>
646
- <th width="330px">Output Structure</th>
647
- </tr>
648
- </thead>
649
- <tbody>
650
- <td>
651
- <pre>
652
- <code>
653
-
654
-
655
-
656
- source
657
- └─┐
658
- ├─ assets
659
- ├─ config
660
- ├─ layout
661
- ├─ locales
662
- ├─ pages
663
- ├─ metafields
664
- │ └─ namespace
665
- │ └─ key.json ㅤ
666
- ├─ sections
667
- ├─ snippets
668
- └─ templates
669
- └─ customers
670
-
671
-
672
-
673
- </code>
674
- </pre>
675
- </td>
676
- <td>
677
- <pre>
678
- <code>
679
- source
680
- └─┐
681
- ├── assets
682
- │ ├─ files
683
- │ ├─ icons
684
- │ └─ images
685
- ├─ data
686
- │ ├─ config
687
- │ ├─ locales
688
- │ └─ metafields
689
- │ └─ namespace
690
- │ └─ key.json ㅤ
691
- ├─ styles
692
- ├─ scripts
693
- └─ views
694
- ├─ customers
695
- ├─ sections
696
- ├─ snippets
697
- ├─ templates
698
- └─ theme.liquid
699
- </code>
700
- </pre>
701
- </td>
702
- <td>
703
- <pre>
704
- <code>
705
- ㅤㅤ
706
-
707
- ㅤ ㅤ
708
- ㅤ ㅤ
709
- ㅤ ㅤ
710
-
711
- output
712
- └─┐
713
- ├─ assets
714
- ├─ config
715
- ├─ locales
716
- ├─ layout
717
- ├─ sections
718
- ├─ snippets
719
- └─ template
720
- └─ customers ㅤ
721
-
722
-
723
-
724
-
725
- </code>
726
- </pre>
727
- </td>
728
- </tr>
729
- </tbody>
730
- </table>
731
-
732
- There is no distributed difference between the **default** and **customized** structures illustrated above. Both would generate an **output** that Shopify understands, requires and reasons with. Only the **input** source locations differ. The **output** Syncify creates will always be written to a standard Shopify theme structure regardless of how you may decide to organize **input** paths. Custom structures give you creative freedom and does not impose a restrictive workflow you may have become behest to working with Dawn and the Shopify CLI. Welcome to the better approach, you're welcome.
733
-
734
- ### Options
735
-
736
- <details>
737
- <summary>
738
- <strong><code>Assets</code></strong>
739
- </summary>
740
- <p>
741
-
742
- An array list of glob path patterns for **asset** files. These will be written in the `assets` directory of your defined `output` path. Please note that you if you transforming CSS, SCSS, SASS or SVG file types using Syncify then you do not need to define those paths here as the `transforms` option will automatically route them, this is the same for assets being processed by spawns.
743
-
744
- **Understanding Spawns in watch mode**
745
-
746
- Syncify will automatically set watch paths of assets when running in watch mode. It will glob match all files being written to your defined `{output}/assets` path but exclude those which you have set to be handled or transformed. For example, if you are using a JavaScript bundler like webpack of rollup, Syncify will watch for any files that are written and handled by these tools or any other spawned process for that matter and once written will trigger an upload.
747
-
748
- </p>
749
- </details>
750
-
751
- <details>
752
- <summary>
753
- <strong><code>Customers</code></strong>
754
- </summary>
755
- <p>
756
-
757
- An array list of glob path patterns to `.liquid` or `.json` **customer** template files. These will be written to the `{output}/templates/customers` directory of your defined `output` path.
758
-
759
- </p>
760
- </details>
761
-
762
- <details>
763
- <summary>
764
- <strong><code>Locales</code></strong>
765
- </summary>
766
- <p>
767
-
768
- An array list of glob path patterns to `.json` **locale** files. These will be written to the `{output}/locales` directory of your defined `output` path.
769
-
770
- </p>
771
- </details>
772
-
773
- <details>
774
- <summary>
775
- <strong><code>Config</code></strong>
776
- </summary>
777
- <p>
778
-
779
- An array list of glob path patterns to `.json` **config** files. These will be written to the `{output}/config` directory of your defined `output` path.
780
-
781
- </details>
782
-
783
- <details>
784
- <summary>
785
- <strong><code>Layout</code></strong>
786
- </summary>
787
- <p>
788
-
789
- An array list of glob path patterns to `.liquid` **layout** files. These will be written to the `{output}/layout` directory of your defined `output` path.
790
-
791
- </p>
792
- </details>
793
-
794
- <details>
795
- <summary>
796
- <strong><code>Sections</code></strong>
797
- </summary>
798
- <p>
799
-
800
- An array list of glob path patterns to `.liquid` **section** files. These will be written to the `sections` directory of your defined `output` path. Sections can be structured within sub-directories. If a section file is determined to be deeply nested in such a way then this option will enable parent directory name prefixing to be applied the output filenames.
801
-
802
- **Understanding Section Processing**
803
-
804
- If the section input path is `source/sections/index/some-file.liquid` then the filename will be prefixed with `index` so when referencing it within themes you'd need to use `index-some-file.liquid` in `{% section %}` tags. Prefixing is helpful when you have a large number of sections and want to avoid name collusion.
132
+ # Author / License
805
133
 
806
- See also [Views](#views).
134
+ Syncify was created and is maintained by [Νικολας Σαββιδης](https://github.com/panoply). Shopify has no affiliation with this project nor do they fund Syncify. Choosing to leverage Syncify helps keep independent projects alive and sends a clear message to Shopify and the teams tasked with enhancing theme development.
807
135
 
808
- </p>
809
-
810
- </details>
811
-
812
- <details>
813
- <summary>
814
- <strong><code>Snippets</code></strong>
815
- </summary>
816
- <p>
817
-
818
- An array list of glob path patterns to `.liquid` **snippet** files. These will be written to the `snippets` directory of your defined `output` path.
819
-
820
- See also [Views](#views).
821
-
822
- </p>
823
- </details>
824
-
825
- <details>
826
- <summary>
827
- <strong><code>Templates</code></strong>
828
- </summary>
829
- <p>
830
-
831
- An array list of glob path patterns to `.json` or `.liquid` **template** files. These will be written to the `templates` directory of your defined `output` path.
832
-
833
- </p>
834
- </details>
835
-
836
- # HOT
837
-
838
- Live reloading is supported in watch mode. Syncify leverages websocket's, XHR and statically served endpoints to provide this capability with zero configuration or the need to install or setup additional tooling. No extensions and no complexities. When you invoke `--hot` syncify will listen for messages sent via websocket on the client and carry out HOT replacements of Assets, Sections, Snippets, Layouts and Templates without triggering full-page refreshes.
839
-
840
- > The HOT reload approach Syncify employs tends to be considerably faster than HOT reloading with the Shopify CLI.
841
-
842
- ### Assets
843
-
844
- SASS/CSS, TypeScript/JavaScript and SVG asset file types are HOT reloaded by swapping out the URL's or containing source with localhost equivalents that Syncify will statically serve.
845
-
846
- ### Sections
847
-
848
- Sections are fetched via the Ajax Section rendering API. Replacements are applied to fragments in real-time.
849
-
850
- ### Snippets, Layouts and Templates
136
+ ### Acknowledgements
851
137
 
852
- In order to provide HOT replacements Syncify employs a mild form of DOM hydration. Snippets, templated and liquid layout files will inject HTML comments `<!-- hot:1aa4f32cf9 -->` containing a UUID before they are uploaded to themes. Syncify will pass this UUID to the client via websocket and once received an XHR (fetch) will be triggered. The response of the XHR request is then parsed and all nodes which proceed the injected UUID comment/s are plucked and swapped in the persisted DOM while leaving unchanged elements intact. The approach employed by Syncify is a mild form DOM hydration that's 10x faster than invoking a hard-refresh.
138
+ Special thanks to a couple of talented developers who have helped with Syncify. This project has been in the making for several years and if not for these individuals, it wouldn't of made it this far.
853
139
 
854
- # Spawn
140
+ - [Kim Skinner](https://github.com/WolfGreyDev)
141
+ - [David Warrington](https://ellodave.dev/)
142
+ - [Mansedan](https://github.com/webdeveman)
855
143
 
856
- The spawn option accepts a **key** > **value** list of commands (i.e: scripts) which can be used when running in **watch** (`--watch`) or **build** (`--build`) modes. The Spawn configuration option allows you to leverage additional build tools and have them execute in parallel with Syncify as child processes.
144
+ ### Donate / Sponsor
857
145
 
858
- Spawned processes allow you use your preferred asset bundlers such as [Rollup](#), [Webpack](#), [Gulp](#) and many more without having to run multiple npm-scripts.
146
+ If you would like to donate or help support this project, then reach out to the folks working at Shopify on [X](https://x.com), via the [Developer Community](https://community.shopify.dev/) or in the Partner slack and tell them that you use Syncify instead of the Shopify CLI
859
147
 
860
- ### Overview
861
-
862
- There are 2 available modes from which you can trigger a spawned process. When a process is spawned in `watch` mode it will run along side Syncify in parallel and execute sequentially in the order of which each spawn is defined. You need to provide any --flags your command (build tool or bundler) requires when running. Spawning a process in `build` mode will trigger spawned commands only 1 time, so it is here where you would provide the compile-only or build-only command, ie: not using watch flags/arguments.
863
-
864
- The Syncify **build** mode re-builds the entire theme and you might choose to run this mode using the Syncify `--prod` flag, if you require context of the environment, mode or action taking place within spawned config files, then take a look at the available [Utilities](#utilities) which Syncify exposes to help conditionally load plugins or trigger different build types in accordance with the Syncify execution cycle.
865
-
866
- ### CLI
867
-
868
- ```bash
869
- --spawn, -s <name> # spawn targeting
870
- ```
871
-
872
- ### Configuration
873
-
874
- <!-- prettier-ignore -->
875
- ```ts
876
- import { defineConfig } from '@syncify/syncify';
877
-
878
- export default defineConfig({
879
-
880
- // ...
881
-
882
- spawn: {
883
- build: {},
884
- watch: {}
885
- }
886
- }
887
- })
888
- ```
889
-
890
- ## Usage
891
-
892
- In most situations you will leverage the spawn option to compile something like TypeScript or JavaScript but it is important to note that this capability is not specific to these assets types. Syncify is using [cross-spawn](https://www.npmjs.com/package/cross-spawn) under the hood to help negate any cross-platform issues that may arise. Below are a couple examples where we spawn up 2 well known JavaScript bundlers and lastly we illustrate how to spawn multiple processes.
893
-
894
- > All stdout/stderr/stdio from spawned processes will be piped through and intercepted by Syncify, which might result in output being stripped of color.
895
-
896
- ### Rollup Example
897
-
898
- If you are processing JavaScript asset files using the [Rollup](https://rollupjs.org/) bundler you can spawn build and watch processes by providing the rollup commands to each mode accordingly. Rollup is a fantastic choice for handling `.js` files. In this example, it is assumed that a `rollup.config.js` file is located in the root of your project.
899
-
900
- <!-- prettier-ignore -->
901
- ```ts
902
- import { defineConfig } from '@syncify/syncify';
903
-
904
- export default defineConfig({
905
- spawn: {
906
- build: {
907
- rollup: 'rollup -c'
908
- },
909
- watch: {
910
- rollup: 'rollup -c -w'
911
- }
912
- }
913
- }
914
- })
915
- ```
916
-
917
- ### Webpack Example
918
-
919
- If you are processing JavaScript asset files using the [Webpack](https://webpack.js.org/) bundler you can spawn build and watch processes by providing the webpack commands to each mode accordingly. You will need to be using the [Webpack CLI](https://github.com/webpack/webpack-cli) module to ensure a successful spawn is triggered.
920
-
921
- > Notice how we also provide the `--color` flag in the spawn. If you omit this flag then the webpack logs will be printed to the CLI without colors, when using webpack you should provide this flag.
922
-
923
- <!-- prettier-ignore -->
924
- ```ts
925
- import { defineConfig } from '@syncify/syncify';
926
-
927
- export default defineConfig({
928
- spawn: {
929
- build: {
930
- webpack: 'webpack --color'
931
- },
932
- watch: {
933
- webpack: 'webpack --watch --color'
934
- }
935
- }
936
- }
937
- })
938
- ```
939
-
940
- ### Multiple Processes
941
-
942
- Though it is unlikely you'd ever need to include 2 different JavaScript bundlers in a project there is nothing stopping you from doing such a thing. For the sake of brevity, the below example illustrates how we can execute multiple spawned child processes to run in parallel with Syncify. Notice how we have also included an additional **gulp** spawn in `build` and `watch` modes. Syncify will trigger these processes in sequentially order, Rollup (1), Gulp (2) and Webpack (3).
943
-
944
- > Aside from attempting to spawn Syncify itself, there is no limitation or restrictions imposed on what you choose to run along side Syncify.
945
-
946
- <!-- prettier-ignore -->
947
- ```ts
948
- import { defineConfig } from '@syncify/syncify';
949
-
950
- export default defineConfig({
951
- spawn: {
952
- build: {
953
- rollup: 'rollup -c',
954
- webpack: 'webpack --color',
955
- gulp: 'gulp watch-task'
956
- },
957
- watch: {
958
- webpack: 'webpack --watch --color',
959
- rollup: 'rollup -c -w',
960
- gulp: 'gulp watch-task'
961
- }
962
- }
963
- }
964
- })
965
- ```
966
-
967
- # Transform
968
-
969
- In Syncify, asset files can be transformed before being written to the defined `output` directory and uploaded to your Shopify store. The `transform` option provides users with control of the "asset pipeline" and Syncify exposes configuration wrappers for handling files together with modern developer tooling.
970
-
971
- Syncify supports built-in and partial processing for the following file types:
972
-
973
- - `.json`
974
- - `.js`
975
- - `.ts`
976
- - `.jsx`
977
- - `.tsx`
978
- - `.css`
979
- - `.scss`
980
- - `.sass`
981
- - `.svg`
982
-
983
- ## Scripts
984
-
985
- Syncify exposes a `script` transform option which supports TypeScript (`.ts` and `.tsx`) and/or JavaScript (`.js` and `.jsx`) bundling using [ESBuild](https://esbuild.github.io/). Script transforms use a pre-defined set of processing configurations and will produce lean JavaScript bundles designed to work seamlessly in development mode or when leveraging HOT reloads. Syncify will also apply refinements to distribution bundles focused on performance when generating production builds for your Shopify theme.
986
-
987
- > ESBuild is the same bundler used under the hood by tools like [vite](https://vitejs.dev/) and [tsup](https://tsup.egoist.sh). If you are using existing tools like Webpack or Rollup, consider adopting ESBuild as its a far superior option.
988
-
989
- ### Installing ESBuild
990
-
991
- In order for you to leverage **script** transforms, you will need to install ESBuild as a development dependency. Syncify will complain if you try to use script options without esbuild installed.
992
-
993
- ```bash
994
- pnpm add esbuild -D
995
- ```
996
-
997
- ### Bundling TypeScript
998
-
999
- The **script** transform option aims to make bundling easy but also extensible for more advanced use cases. Syncify will automatically detect `tsconfig.json` (or `jsconfig.json`) files located in your workspace and respect processing options defined within. By default, Syncify will produce **ESM** module formats that output in **ES2016** but you can also generate **IIFE** bundles and even inline code as a snippets within `<script></script>` tags.
1000
-
1001
- The `script` options accepts several different structures and it is up to you how you wish to provide settings. The below code sample depicts the default configuration structure:
1002
-
1003
- <!--prettier-ignore-->
1004
- ```ts
1005
- import { defineConfig } from '@syncify/syncify';
1006
-
1007
- export default defineConfig({
1008
- transforms: {
1009
- script: [
1010
- {
1011
- input: [],
1012
- format: 'esm',
1013
- target: 'es2016',
1014
- snippet: false,
1015
- rename: '',
1016
- external: [],
1017
- watch: [],
1018
- esbuild: {}
1019
- }
1020
- ]
1021
- }
1022
- })
1023
- ```
1024
-
1025
- You may prefer to use rename (entry point) structures instead. When we are using rename entry points the prefix path expects either `snippets/` or `assets/` be provided. When passing `snippets/` then a snippet will be generated, whereas `assets/` will generate a `.js` file.
1026
-
1027
- > Rename entry points accept `[file]`, `[dir]` and `[ext]` placeholders.
1028
-
1029
- <!--prettier-ignore-->
1030
- ```ts
1031
- import { defineConfig } from '@syncify/syncify';
1032
-
1033
- export default defineConfig({
1034
- transforms: {
1035
- script: {
1036
-
1037
- // Producing 2 inline snippet <script> bundles
1038
- // Output will be slideshow.js.liquid and search-form.js.liquid
1039
- 'snippets/[file][ext]': [
1040
- 'scripts/sections/slideshow.ts',
1041
- 'scripts/sections/search-form.ts'
1042
- ]
1043
-
1044
- // Producing an IIFE script as an asset
1045
- // The return value is accessible via window.Foo
1046
- 'assets/foo.min.js': {
1047
- input: 'scripts/index.ts',
1048
- format: 'iife',
1049
- globalName: 'window.Foo,
1050
- }
1051
- }
1052
- }
1053
- })
1054
- ```
1055
-
1056
- ## Styles
1057
-
1058
- ###### TAILWIND IS NOT YET SUPPORT
1059
-
1060
- Syncify exposes a `style` transform option which can be used for CSS (`.css`) and SCSS/SASS (`.scss` or `.sass`) bundling. Style transform support is made possible by using compilers like [Dart SASS](#), [PostCSS](#) and/or [Tailwind](#). The `style` option provides developers with replicated configuration control but you may also prefer to use standard config files (e.g: `postcss.config.js`) which Syncify also supports.
1061
-
1062
- Style transforms help alleviate the complexities sometimes involved in setting up these tools so you can easily process asset specific stylesheets or generate output as a **snippet** within `<style></style>` tags.
1063
-
1064
- ### SASS Support
1065
-
1066
- Syncify provides SCSS/SASS transform support for `.scss` and `.sass` file types using [Dart SASS](#). Using SASS required you to install the Dart module as a development dependency in your project. Syncify will complain if you try to use SASS transforms without Dart SASS installed.
1067
-
1068
- ```bash
1069
- pnpm add sass -D
1070
- ```
1071
-
1072
- ### Tailwind Support ~ COMING SOON
1073
-
1074
- Syncify supports TailwindCSS for CSS processing. If you require transform support for Tailwind, you need to install the TailwindCSS module as a development dependency in your project. Syncify will ignore Tailwind class name occurrences without the module installed.
1075
-
1076
- ```bash
1077
- pnpm add tailwindcss -D
1078
- ```
1079
-
1080
- > Tailwind is not yet available in the beta.
1081
-
1082
- ### PostCSS Support
1083
-
1084
- In addition to SASS transformation, Syncify also support CSS (post)-processing using [PostCSS](#). If you wish have Syncify handle CSS transforms then you need to install **PostCSS** as a development dependency. Syncify will complain if you try to use PostCSS transforms without PostCSS installed.
1085
-
1086
- > Provide PostCSS plugins and any specific settings within the `postcss.config.js` file.
1087
-
1088
- ```
1089
- pnpm add postcss -D
1090
- ```
1091
-
1092
- **Please note:** If you are using Syncify to compile SASS files, then by default the transformed CSS will be passed to PostCSS.
1093
-
1094
- ### Usage
1095
-
1096
- In the below example we are generating multiple stylesheets and compiling both SCSS and CSS file types. The example illustrates how one can leverage Syncify together with [Dart SASS](#), [PostCSS](#) and additional node modules like the Bootstrap framework.
1097
-
1098
- > **Please Note** You will need to remove the comments from the code example if you are copy and pasting it into your `package.json` file. JSON with Comments is not supported in `package.json` files.
1099
-
1100
- <!-- prettier-ignore-->
1101
- ```ts
1102
- import { defineConfig } from '@syncify/syncify'
1103
-
1104
- export default defineConfig({
1105
- transforms: {
1106
- style: {
1107
- 'assets/stylesheet.min.css': {
1108
- input: 'styles/stylesheet.scss',
1109
- watch: ['styles/sections/*'],
1110
- postcss: true,
1111
- sass: true
1112
- },
1113
- 'snippets/css.liquid': {
1114
- input: 'styles/vars.css.liquid',
1115
- postcss: true,
1116
- sass: true
1117
- },
1118
- 'assets/bootstrap.min.scss': {
1119
- input: 'styles/vendors/bootstrap.scss',
1120
- style: 'expanded',
1121
- includePaths: ['node_modules/bootstrap']
1122
- }
1123
- }
1124
- }
1125
- })
1126
- ```
1127
-
1128
- ## Views
1129
-
1130
- The `views` transform option controls how `.liquid` file types should be handled. Snippets, Templates, Sections and Layout paths are typically where liquid files are used. Options defined here will be used when Syncify is processing such types.
1131
-
1132
- ### Sections
1133
-
1134
- Syncify provides sub-directory grouping and rename prefixing capabilities when handling theme sections. You might be accustom to storing sections within a single directory and despite Shopify using this approach in their Dawn theme, it is restrictive and rather chaotic to the developer experience. A far better approach is to take advantage of the sub-directory grouping feature which Syncify provides.
1135
-
1136
- **Sub-directory Grouping**
1137
-
1138
- Shopify shipped "sections everywhere" capabilities in Online Store 2.0 and while this is a great feature to have it opens the door to inconsistent structures. The logic of Shopify here has been to provide store developers "freedom" but it is a double edged sword. Sections everywhere has consequently resulted in developers indirectly facilitating merchants the ability to leverage sections on pages where they should otherwise be avoided. For instance, enabling merchants to add a featured-collection, featured-blog or full-screen hero image to product pages is not necessarily a good idea. Developers may be more inclined to provide such section types when working from within a single directory structure that is without organized order.
1139
-
1140
- Shopify tends to push a DRY infrastructure approach for the theme development wherein store sections _should_ be capable of appropriation within any template. This is great in theory but in order to achieve aesthetic fluidity it is not realistic when we go beyond a Dawn structure and even there we find the utter chaos. Approaching things in a compartmentalized manner is just better approach but this is difficult when working from a single level structured directory.
1141
-
1142
- Grouping section into sub-directories results is far better consideration, organization and order at the development level. Syncify provides these capabilities while still respecting developer personal preferences. Below is an example of how you can leverage Syncify to use sub-directories together with pre-fixing capabilities.
1143
-
1144
- <!-- prettier-ignore -->
1145
- <table>
1146
- <thead>
1147
- <tr>
1148
- <th>Syncify Options</th>
1149
- <th>Source Structure</th>
1150
- <th>Theme Output</th>
1151
- </tr>
1152
- </thead>
1153
- <tbody>
1154
- <td>
1155
-
1156
- <!-- prettier-ignore -->
1157
- ```json
1158
- {
1159
- "paths": {
1160
- "sections": [
1161
- "sections/**/*"
1162
- ]
1163
- },
1164
- "sections": {
1165
- "prefix": true,
1166
- "prefixSeparator": "-",
1167
- "prefixDuplicates": true,
1168
- "globals": [
1169
- "shared",
1170
- "layout",
1171
- "related.liquid"
1172
- ]
1173
- }
1174
- }
1175
- ```
1176
-
1177
- </code>
1178
- </td>
1179
- <td>
1180
- <pre>
1181
- <code>ㅤ
1182
- source
1183
-
1184
- └─ sections
1185
- ├─ collection
1186
- │ ├─ filter.liquid
1187
- │ └─ search.liquid
1188
- ├─ product
1189
- │ ├─ images.liquid
1190
- │ ├─ on-sale.liquid
1191
- │ └─ related.liquid
1192
- ├─ layout
1193
- │ ├─ header.liquid
1194
- │ └─ footer.liquid
1195
- └─ shared
1196
- ├─ banner.liquid
1197
- └─ slideshow.liquid
1198
- </code>
1199
- </pre>
1200
- </td>
1201
- <td>
1202
- <pre>
1203
- <code>
1204
-
1205
-
1206
- theme
1207
-
1208
- └─ sections
1209
- ├─ banner.liquid
1210
- ├─ collection-filter.liquid
1211
- ├─ collection-search.liquid
1212
- ├─ footer.liquid
1213
- ├─ header.liquid
1214
- ├─ product-images.liquid
1215
- ├─ product-on-sale.liquid
1216
- ├─ related.liquid
1217
- └─ slideshow.liquid
1218
-
1219
-
1220
- </code>
1221
- </pre>
1222
- </td>
1223
- </tr>
1224
- </tbody>
1225
- </table>
1226
-
1227
- Notice how we can nest sections within sub-directories and also apply prefixing to the section output filenames. We also inform Syncify that some of our sections should be considered **global** and this allows those defined there to pass through without name augmentation (prefixing). We passed a `true` value to the `prefix` option, this informed Syncify that section files which are not explicitly defined as **global** should have their output filename prefixed with the **parent** directory name they are contained within.
1228
-
1229
- <details>
1230
- <summary>
1231
- <strong><code>Sections</code></strong>
1232
- </summary>
1233
- <p>
1234
-
1235
- **prefix**
1236
-
1237
- **prefixDuplicates**
1238
-
1239
- **prefixSeparator**
1240
-
1241
- **globals**
1242
-
1243
- </p>
1244
- </details>
1245
-
1246
- <details>
1247
- <summary>
1248
- <strong><code>Minify</code></strong>
1249
- </summary>
1250
- <p>
1251
-
1252
- **env**
1253
-
1254
- `never`
1255
-
1256
- **minifyJS**
1257
-
1258
- `boolean`
1259
-
1260
- **minifyCSS**
1261
-
1262
- `boolean`
1263
-
1264
- **removeComments**
1265
-
1266
- `boolean`
1267
-
1268
- **collapseWhitespace**
1269
-
1270
- `boolean`
1271
-
1272
- **trimCustomFragments**
1273
-
1274
- `boolean`
1275
-
1276
- **ignoreCustomFragments**
1277
-
1278
- `string[]`
1279
-
1280
- **minifySectionSchema**
1281
-
1282
- `boolean`
1283
-
1284
- **removeLiquidComments**
1285
-
1286
- `boolean`
1287
-
1288
- **removeAttributeNewlines**
1289
-
1290
- `boolean`
1291
-
1292
- **removeRedundantDashTrims**
1293
-
1294
- `boolean`
1295
-
1296
- **ignoredLiquidTags**
1297
-
1298
- `string[]`
1299
-
1300
- **exclude**
1301
-
1302
- `string[]`
1303
-
1304
- </p>
1305
- </details>
1306
-
1307
- ### Json
1308
-
1309
- The `json` transform option controls how `.json` files should be processed. Templates, Config, Locales and Metafields paths typically where JSON files are used. Options defined here will be used when Syncify is processing these file types. In addition, Syncify will also apply handle any Assets that have `.json` extension using these options.
1310
-
1311
- <details>
1312
- <summary>
1313
- <strong><code>Spaces</code></strong>
1314
- </summary>
1315
- <p>
1316
-
1317
- Beautification `2`
1318
-
1319
- </p>
1320
- </details>
1321
-
1322
- <details>
1323
- <summary>
1324
- <strong><code>Minify</code></strong>
1325
- </summary>
1326
- <p>
1327
-
1328
- Minification options
1329
-
1330
- **env**
1331
-
1332
- `never`
1333
-
1334
- **removeSchemaRefs**
1335
-
1336
- `true`
1337
-
1338
- **exclude**
1339
-
1340
- `string[]`
1341
-
1342
- </p>
1343
- </details>
1344
-
1345
- ### Styles
1346
-
1347
- The `styles` transform option accepts an array type. This option requires you have [Dart SASS](#) and/or [PostCSS](#) installed as a development dependencies in your project. Syncify supports the handling of `.sass`, `.scss` and `.css` file types using these tools and the options are convenience wrappers for them.
1348
-
1349
- <details>
1350
- <summary>
1351
- <strong><code>Input</code></strong>
1352
- </summary>
1353
- <p>
1354
-
1355
- Path `string[]` or `string`
1356
-
1357
- </p>
1358
- </details>
1359
-
1360
- <details>
1361
- <summary>
1362
- <strong><code>Rename</code></strong>
1363
- </summary>
1364
- <p>
1365
-
1366
- Rename Options
1367
-
1368
- `string[]`
1369
-
1370
- </p>
1371
- </details>
1372
-
1373
- <details>
1374
- <summary>
1375
- <strong><code>Watch</code></strong>
1376
- </summary>
1377
- <p>
1378
-
1379
- Watch Options
1380
-
1381
- `string[]`
1382
-
1383
- </p>
1384
- </details>
1385
-
1386
- <details>
1387
- <summary>
1388
- <strong><code>Snippet</code></strong>
1389
- </summary>
1390
- <p>
1391
-
1392
- `boolean`
1393
-
1394
- </p>
1395
- </details>
1396
-
1397
- <details>
1398
- <summary>
1399
- <strong><code>PostCSS</code></strong>
1400
- </summary>
1401
- <p>
1402
-
1403
- PostCSS options
1404
-
1405
- **env**
1406
-
1407
- `all`, `dev`, `prod` `never`
1408
-
1409
- </p>
1410
- </details>
1411
-
1412
- <details>
1413
- <summary>
1414
- <strong><code>SASS</code></strong>
1415
- </summary>
1416
- <p>
1417
-
1418
- **logWarnings**
1419
-
1420
- `boolean`
1421
-
1422
- **sourcemap**
1423
-
1424
- `boolean`
1425
-
1426
- **style**
1427
-
1428
- `compressed` or `expanded`
1429
-
1430
- </p>
1431
- </details>
1432
-
1433
- # Processors
1434
-
1435
- In Syncify, **processors** refer to the external tools used in [Transforms](#transform) (i.e: SVGO, ESBuild SASS etc). The `processors` configuration option provides developers a point of control for configuring these (supported) _third party_ modules. The configurations defined in processors will used as the defaults bundling options of each transform and allows developers to retain a single point of control from which all _third party_ processor operations will refer, this saves you having to include multiple external config files in your projects workspace.
1436
-
1437
- <!-- prettier-ignore -->
1438
- ```ts
1439
- import { defineConfig } from '@syncify/cli'
1440
-
1441
- export default defineConfig({
1442
-
1443
- // ...
1444
-
1445
- processors: {
1446
- json: {}, // applied to json transforms
1447
- esbuild: {}, // applied to script transforms
1448
- sass: {}, // applied to style transforms
1449
- postcss: [], // applied to style transforms
1450
- tailwind: {}, // applied to style transforms
1451
- svgo: {}, // applied to svg transforms
1452
- sprite: {}, // applied to svg transforms
1453
- sharp: {}, // applied to img transforms
1454
- }
1455
- })
1456
- ```
1457
-
1458
- > Using processors requires installing the relative module you'd like to leverage. This is an opt-in capability.
1459
-
1460
- ### External Config Files
1461
-
1462
- Some third party tools allow (or require) config file usage (e.g: `postcss.config.js`, `tailwind.config.js` etc etc). Syncify will check for the existence of configuration files in the workspace and use them as the processor defaults. In situations where an external config file is detected and you've defined custom `processor` settings which differ from the Syncify defaults then options of the external config will overwritten (or merged) by those defined on `processor` configuration.
1463
-
1464
- Say you're using a `postcss.config.js` file to provide a couple of plugins in your project, for example:
1465
-
1466
- <!-- prettier-ignore -->
1467
- ```js
1468
- // postcss.config.js
1469
-
1470
- module.exports = {
1471
- plugins: [
1472
- require('postcss-nested')(),
1473
- require('autoprefixer')()
1474
- ]
1475
- };
1476
-
1477
- ```
1478
-
1479
- Syncify will automatically detect and digest this file at runtime. It will use the export value when processing CSS with PostCSS and will consider it the **default** value, assigning it to `processors.postcss`. Instead of providing a `postcss.config.js` file, you _could_ instead just pass this to the **postcss** processor option, for example:
1480
-
1481
- <!-- prettier-ignore -->
1482
- ```js
1483
- // syncify.config.ts
1484
-
1485
- import { defineConfig } from '@syncify/cli';
1486
-
1487
- export default defineConfig({
1488
- // ...
1489
- processors: {
1490
- postcss: [
1491
- require('postcss-nested')(),
1492
- require('autoprefixer')()
1493
- ]
1494
- }
1495
- });
1496
- ```
1497
-
1498
- ### Transform Overrides
1499
-
1500
- You can overwrite processor defaults on a per-file basis at the transform level. Each transform exposes a processor property which accepts the same options which will apply an immutable merge with processor defaults. This is helpful when you require file specific transforms.
1501
-
1502
- Take the following code sample, notice how we've passed an SASS override on certain files. In this example the `style.scss` transform will use the `processor.sass` configuration, whereas the the `example.scss` file will override the `processor.sass` defaults and use a different set of configuration options.
1503
-
1504
- <!-- prettier-ignore -->
1505
- ```js
1506
- // syncify.config.ts
1507
-
1508
- import { defineConfig } from '@syncify/cli';
1509
-
1510
- export default defineConfig({
1511
- // ...
1512
- processor: {
1513
- sass: {
1514
- sourcemap: true,
1515
- style: 'compressed',
1516
- include: ['node_modules/'], // the style.scss include path
1517
- }
1518
- },
1519
- transform: {
1520
- style: [
1521
- {
1522
- input: 'styles/style.scss',
1523
- postcss: true
1524
- },
1525
- {
1526
- input: 'styles/example.scss',
1527
- snippet: true,
1528
- sass: {
1529
- style: 'expanded', // we override the output style
1530
- include: ['some/dir'] // we override the include path
1531
- }
1532
- }
1533
- ]
1534
- }
1535
- });
1536
- ```
1537
-
1538
- ### Usage Proposition
1539
-
1540
- Processors (and transforms) are optional in Syncify and may not fit your use case but there is an added benefit to using them. If you are leveraging HOT reloads or require different outputs be generated, then they are a great help. They also take a lot of the guess work out of bundling, so you can focus on writing code without worrying about bundler configurations.
1541
-
1542
- [Spawn](#spawn) processes are another option available for cases where you require a different complier which is not supported by Syncify, but please note that spawned processes will not apply HOT reloads and execute in child process. Whatever the case may be, it is important you weigh up the usage proposition for your project and determine which works best for you and your development workflow.
1543
-
1544
- ### Supported Processors
1545
-
1546
- Syncify provides extendable support with the following build tools:
1547
-
1548
- - [ESBuild](#esbuild)
1549
- - [SASS](#sass)
1550
- - [PostCSS](#postcss)
1551
- - [Tailwind](#tailwind-support)
1552
- - [SVGO](#svgo)
1553
- - [Sprite](#sprite)
1554
- - [Sharp](#sharp)
1555
-
1556
- # ESBuild
1557
-
1558
- Syncify provides integrated support with ESBuild for processing TypeScript, JavaScript, JSX and TSX file types. ESBuild provides wonderful capabilities like code splitting and tree shaking.
1559
-
1560
- See also [Script Transforms](#).
1561
-
1562
- ### Using Config File
1563
-
1564
- ESBuild Configuration files `esbuild.config.js` are not supported for script transforms.
1565
-
1566
- ### Using Processors
1567
-
1568
- The `esbuild` property is were ESBuild configuration option defaults can be provided.
1569
-
1570
- <!-- prettier-ignore -->
1571
- ```ts
1572
- import { defineConfig } from '@syncify/cli'
1573
-
1574
- export default defineConfig({
1575
- processors: {
1576
- esbuild: {} // ESBuild Options
1577
- }
1578
- })
1579
- ```
1580
-
1581
- # SASS
1582
-
1583
- Syncify provides integrated support with SASS Dart for processing SASS/SCSS file types. Syncify implements its own handling when for usage with SASS and allows you to use it together with [PostCSS](#postcss).
1584
-
1585
- See also [Style Transforms](#).
1586
-
1587
- ### Config File is not supported
1588
-
1589
- SASS Configuration files are not supported for style transforms.
1590
-
1591
- ### Using Processors
1592
-
1593
- The `sass` property is were SASS configuration option defaults can be provided.
1594
-
1595
- <!-- prettier-ignore -->
1596
- ```ts
1597
- import { defineConfig } from '@syncify/cli'
1598
-
1599
- export default defineConfig({
1600
- processors: {
1601
- sass: {} // SASS Options
1602
- }
1603
- })
1604
- ```
1605
-
1606
- # PostCSS
1607
-
1608
- Syncify provides integrated support with PostCSS for processing CSS file types. You can leverage PostCSS together with the SASS processor for CSS files.
1609
-
1610
- See also [Style Transforms](#).
1611
-
1612
- ### Using Config File
1613
-
1614
- Provide a `postcss.config.js` file in the root of your project or within the defined `config` path.
1615
-
1616
- ### Using Processors
1617
-
1618
- The `postcss` property accepts an array list of PostCSS plugins.
1619
-
1620
- <!-- prettier-ignore -->
1621
- ```ts
1622
- import { defineConfig } from '@syncify/cli'
1623
-
1624
- export default defineConfig({
1625
- processors: {
1626
- postCSS: [] // PostCSS Plugins
1627
- }
1628
- })
1629
- ```
1630
-
1631
- # SVGO
1632
-
1633
- Syncify provides integrated support with SVGO for processing SVG file types. If you would like to produce SVG Sprites, then refer to [Sprites](#) section which uses SVGO under the hood.
1634
-
1635
- See also [SVG Transforms](#).
1636
-
1637
- ### Using Config File
1638
-
1639
- Provide a `svgo.config.js` file in the root of your project or within the defined `config` path.
1640
-
1641
- ### Using Processors
1642
-
1643
- The `svgo` property accepts SVGO configuration options.
1644
-
1645
- <!-- prettier-ignore -->
1646
- ```ts
1647
- import { defineConfig } from '@syncify/cli'
1648
-
1649
- export default defineConfig({
1650
- processors: {
1651
- svgo: {} // SVGO Options
1652
- }
1653
- })
1654
- ```
1655
-
1656
- # Sprite
1657
-
1658
- Syncify provides integrated support for creating SVG Sprites using [SVG Sprites](#). SVG Sprite is a low level module that optimizes SVGs and bakes them into sprites that Syncify can inline and output.
1659
-
1660
- See also [SVG Transforms](#).
1661
-
1662
- ### Config File is not supported
1663
-
1664
- SVG Sprites Configuration files are not supported for Sprite transforms.
1665
-
1666
- ### Using Processors
1667
-
1668
- The `sprite` property accepts SVG Sprite configuration options.
1669
-
1670
- <!-- prettier-ignore -->
1671
- ```ts
1672
- import { defineConfig } from '@syncify/cli'
1673
-
1674
- export default defineConfig({
1675
- processors: {
1676
- sprite: {} // SVG Sprite Options
1677
- }
1678
- })
1679
- ```
1680
-
1681
- # Sharp
1682
-
1683
- Syncify provides integrated support for convert large images in common formats to smaller, web-friendly JPEG, PNG, WebP, GIF and AVIF images of varying dimensions using the Sharp.
1684
-
1685
- See also [Image Transforms](#)
1686
-
1687
- ### Config File is not supported
1688
-
1689
- Sharp Configuration files are not supported for Image transforms.
1690
-
1691
- ### Using Processors
1692
-
1693
- The `sharp` property accepts Sharp configuration options.
1694
-
1695
- <!-- prettier-ignore -->
1696
- ```ts
1697
- import { defineConfig } from '@syncify/cli'
1698
-
1699
- export default defineConfig({
1700
- processors: {
1701
- sharp: {} // Sharp Options
1702
- }
1703
- })
1704
- ```
1705
-
1706
- # Terser
1707
-
1708
- The **Terser** option is for minification configuration options. Syncify supports minification and compression of Liquid, HTML JSON and also provides handling around Script and Style Transform file types. Terse output is core to theme development using Syncify and developers should indeed get into a habit a distributing themes in terse a format.
1709
-
1710
- ### Does Liquid Minification Matter?
1711
-
1712
- When we are talking about Liquid syntax specifically, there is no real measurable performance increase one gets removing whitespace and newlines but Syncify does more than just strip whitespace, it also performs code elimination. The Syncify minification process will remove comments, strip extraneous delimiter trims and where possible it replaces syntax occurrences for faster equivalents.
1713
-
1714
- ### Usage
1715
-
1716
- Produce terse output by passing `--terse` command flag. The `--prod` flag will also produce terse output. You can pass a boolean `false` to options to skip minification.
1717
-
1718
- ### Terse Options
1719
-
1720
- Below is is the default configuration Syncify uses for minification.
1721
-
1722
- <!-- prettier-ignore -->
1723
- ```ts
1724
- import { defineConfig } from '@syncify/cli'
1725
-
1726
- export default defineConfig({
1727
- terser: {
1728
- json: {
1729
- assets: true,
1730
- config: true,
1731
- locales: true,
1732
- metafields: true,
1733
- templates: true,
1734
- exclude: []
1735
- },
1736
- view: {
1737
- collapseWhitespace: true,
1738
- minifySchema: true,
1739
- minifyScript: true,
1740
- minifyStyle: true,
1741
- replaceSugar: true,
1742
- removeComments: true,
1743
- stripDashes: true,
1744
- swapAssign: true,
1745
- exclude: []
1746
- },
1747
- // Requires ESBuild to be installed
1748
- script: {
1749
- mangleProps: true,
1750
- keepNames: false,
1751
- legalComments: true,
1752
- keepNames: false,
1753
- legalComments: "inline",
1754
- mangleProps: undefined,
1755
- minifyIdentifiers: true,
1756
- minifySyntax: true,
1757
- minifyWhitespace: true,
1758
- mangleQuoted: true,
1759
- exclude: []
1760
- }
1761
- }
1762
- });
1763
- ```
1764
-
1765
- # CLI Usage
1766
-
1767
- Syncify ships with a powerful command line interface that supports prompt execution. If you have installed Syncify globally, you can call `syncify` or `sync` from any project but you should avoid this and instead install the module as a development dependency on a per-project basis.
1768
-
1769
- If you are using a package manager like [pnpm](https://pnpm.js.org/en/cli/install) you can simply call `pnpm syncify` (or `pnpm sync`) but if you are using npm or yarn then you may need to create reference script within your `package.json` file, eg:
1770
-
1771
- ```json
1772
- {
1773
- "scripts": {
1774
- "syncify": "syncify"
1775
- }
1776
- }
1777
- ```
1778
-
1779
- > If you are not using [pnpm](https://pnpm.js.org/en/cli/install) then you should really consider adopting it within your stack. It is a wonderful addition to any JavaScript project.
1780
-
1781
- ### Commands
1782
-
1783
- ### PARTIALLY INCOMPLETE - NOT ALL COMMANDS WORK
1784
-
1785
- The Syncify CLI supports the following commands.
1786
-
1787
- ```bash
1788
- Default:
1789
- syncify Starts interactive CLI command prompt
1790
-
1791
- Aliases:
1792
- sync An alias of syncify (can be used instead of syncify)
1793
-
1794
- Commands:
1795
- syncify Starts interactive CLI command prompt
1796
- syncify <store> --flags Store name or comma separated list of stores and flags
1797
-
1798
- Flags:
1799
- -t, --theme <targets> A comma separated list of theme targets
1800
- -b, --build Triggers a build, use with upload to run build before uploading
1801
- -w, --watch Starts watching for changes of files building when they occur
1802
- -u, --upload Uploads theme to online store, use with -t to target theme
1803
- -d, --download Downloads themes/s from specified stores
1804
- -c, --config <path> An optional config path to the syncify.config.js file.
1805
- -h, --hot HOT Reloading (available in watch mode only)
1806
- -p, --package Package theme and export to a .zip file
1807
- -s, --spawn, <name> Target a specific spawn (use with -w or -b flags to specify mode)
1808
- -o, --output <path> A path value (used in download and build mode only)
1809
- -h, --help, Prints command list and some help information
1810
- -f, --filter <filter> Query online store data API, eg: themes, metafields assets
1811
- -v, --version <action> Version control resource mode (see version arguments)
1812
-
1813
- Resource Modes:
1814
- --metafields Metafields resource mode
1815
- --locales Locales resource mode
1816
- --settings Settings resource mode
1817
- --redirects Redirects resource mode
1818
-
1819
- Version Arguments:
1820
- patch Increments the package.json version patch, eg: 1.0.0 > 1.0.1
1821
- minor Increments the package.json version minor, eg: 1.0.0 > 1.1.0
1822
- major Increments the package.json version major, eg: 1.0.0 > 2.0.0
1823
-
1824
- Operation Flags:
1825
- --clean Removes all output files, use with --build to clean before bundling
1826
- --status Checks development environment and connections are valid.
1827
- --pull Pull data from online store
1828
- --merge Merge online data with local references
1829
- --force Forces a sync, replacing remote source with local one
1830
- --silent Silence the logger, omit only errors
1831
-
1832
- Generator Flags:
1833
- --vsc Generates JSON schema spec for vscode users
1834
- --strap <name> Generates a Syncify theme strap, eg: --strap dawn
1835
-
1836
- Environment Flags:
1837
- --dev, --development Run in development mode (default)
1838
- --prod, --production Run in production mode
1839
- ```
1840
-
1841
- > Please keep in mind that not all commands are active as the project is still in beta.
1842
-
1843
- ## Examples
1844
-
1845
- CLI usage aims to be as simple as possible. A typical project will be targeting a single Shopify theme but you can target multiple themes and stores in a seamless manner. When targeting multiple stores or themes the CLI employs a flag based naming approach.
1846
-
1847
- **Generate theme targets**
1848
-
1849
- ```bash
1850
- $ syncify store-name -q themes
1851
- ```
1852
-
1853
- Prompt interface will be initialized
1854
-
1855
- 1. Target **store-name**
1856
- 2. Initialize Query resource
1857
- 3. Inform query we want the "themes" endpoint
1858
-
1859
- **Generate local metafields**
1860
-
1861
- ```bash
1862
- $ syncify store-name --metafields --pull
1863
- ```
1864
-
1865
- Prompt interface will be initialized
1866
-
1867
- 1. Target **store-name**
1868
- 2. Initialize Metafields resource
1869
- 3. Pull data from online-store
1870
-
1871
- **Upload theme to online store**
1872
-
1873
- ```bash
1874
- $ syncify store-name -t theme-1,theme-2 --clean -b -u --prod
1875
- ```
1876
-
1877
- Exchange interface will be initialized
1878
-
1879
- 1. Target **store-name**
1880
- 2. Theme targets are **theme-1** and **theme-2**
1881
- 3. Trigger Clean
1882
- 4. Trigger Build (production build because of --prod flag)
1883
- 5. Trigger Upload
1884
-
1885
- **Watching 1 store and 1 theme**
1886
-
1887
- ```bash
1888
- $ syncify shop -w -t dev
1889
- ```
1890
-
1891
- <details>
1892
- <summary>
1893
- Breakdown
1894
- </summary>
1895
-
1896
- The above command is calling `watch` on a store named `cool-shop` and will upload changes to a theme named `dev`. We are using the shorthand `--theme` flag (`-t`) to inform upon the theme we want changes uploaded.
1897
-
1898
- </details>
1899
-
1900
- <details>
1901
- <summary>
1902
- Configuration
1903
- </summary>
1904
-
1905
- The `package.json` configuration for the command would look like this:
1906
-
1907
- ```jsonc
1908
- {
1909
- "syncify": {
1910
- "stores": {
1911
- "domain": "cool-shop", // The store name
1912
- "themes": {
1913
- "dev": 123456789 // The theme id and target name
1914
- }
1915
- }
1916
- }
1917
- }
1918
- ```
1919
-
1920
- </details>
1921
-
1922
- **Watching 1 store and 2 themes**
1923
-
1924
- ```bash
1925
- $ syncify shop -t dev,prod -w
1926
- ```
1927
-
1928
- <details>
1929
- <summary>
1930
- Breakdown
1931
- </summary>
1932
-
1933
- The above command is calling `watch` on a store named `my-shop` and will upload changes to 2 different themes in that store we have named `dev` and `prod`.
1934
-
1935
- </details>
1936
-
1937
- <details>
1938
- <summary>
1939
- Configuration
1940
- </summary>
1941
-
1942
- The `package.json` configuration for the command would look like this:
1943
-
1944
- ```jsonc
1945
- {
1946
- "syncify": {
1947
- "stores": {
1948
- "domain": "my-shop", // The store name
1949
- "themes": {
1950
- "dev": 123456789, // The theme id and target name
1951
- "prod": 123456789 // The theme id and target name
1952
- }
1953
- }
1954
- }
1955
- }
1956
- ```
1957
-
1958
- </details>
1959
-
1960
- **Watching 2 stores and multiple themes**
1961
-
1962
- ```bash
1963
- $ syncify shop1,shop2 --shop1=test --shop2=dev,stage,prod -w
1964
- ```
1965
-
1966
- <details>
1967
- <summary>
1968
- Breakdown
1969
- </summary>
1970
-
1971
- The above command is calling `watch` on 2 stores, `shop1` and `shop2`. We are targeting a theme named `test` in the store `shop1` and 3 different themes in `shop2` named `dev`, `stage` and `prod`. Syncify will upload changes to both store and all the defined themes. Notice how we target different store themes in the command using the store name as a flag.
1972
-
1973
- </details>
1974
-
1975
- <details>
1976
- <summary>
1977
- Configuration
1978
- </summary>
1979
-
1980
- The `package.json` configuration for the command would look like this:
1981
-
1982
- ```json
1983
- {
1984
- "syncify": {
1985
- "stores": [
1986
- {
1987
- "domain": "shop1", // The store name
1988
- "themes": {
1989
- "test": 123456789 // The theme id and target name
1990
- }
1991
- },
1992
- {
1993
- "domain": "shop2", // The store name
1994
- "themes": {
1995
- "dev": 123456789,
1996
- "stage": 123456789,
1997
- "prod": 123456789
1998
- }
1999
- }
2000
- ]
2001
- }
2002
- }
2003
- ```
2004
-
2005
- </details>
2006
-
2007
- ### Prompts
2008
-
2009
- Syncify provides a helpful command prompt feature. Running `syncify` will provide you a simple prompt interface from which you can use to explore endpoints directly from your CLI or trigger commands.
2010
-
2011
- **Options**
2012
-
2013
- **Queries**
2014
-
2015
- # API
2016
-
2017
- Syncify can be initialized within scripts. This approach is a little more feature-full and allows you to integrate it with different build tools. You can hook into the transit process of files and apply modifications before they are uploaded to your store/s with this approach.
2018
-
2019
- ### Usage
2020
-
2021
- Syncify exports a function that has several methods which you can use to trigger specific modes. The default export can also target multiple hooks in accordance with what was passed from the command line.
2022
-
2023
- ```ts
2024
- import { syncify } from '@syncify/cli';
2025
-
2026
- // Build hook
2027
- syncify.build(options: {}, async function(content?: Buffer): Promise<Buffer|string|void|false>);
2028
-
2029
- // Watch hook
2030
- syncify.watch(options: {}, async function(content?: Buffer): Promise<Buffer|string|void|false>);
2031
-
2032
- // Upload hook
2033
- syncify.upload(options: {}, async function(content?: Buffer): Promise<Buffer|string|void|false>);
2034
-
2035
- // Download hook
2036
- syncify.download(options: {}, async function(content?: Buffer): Promise<Buffer|string|void|false>);
2037
-
2038
- // Targeting all hooks
2039
- syncify(options: {})({
2040
- async build(content?: Buffer): Promise<Buffer|string|void|false>,
2041
- async watch(content?: Buffer): Promise<Buffer|string|void|false>,
2042
- async upload(content?: Buffer): Promise<Buffer|string|void|false>,
2043
- async download(content?: Buffer): Promise<Buffer|string|void|false>,
2044
- });
2045
-
2046
- ```
2047
-
2048
- ### Utilities
2049
-
2050
- Utilities will return some basic information about the Syncify instance. These are extremely helpful when when you are executing [spawned](#spawn) processes and need to control what feature to load. For example, if you are spawning a webpack process for compiling JavaScript assets and need to inform upon watch mode you'd use `util.resource('watch')` utility which returns a boolean value when running in watch mode.
2051
-
2052
- ```typescript
2053
- import { util, env } from '@syncify/cli'
2054
-
2055
- // Environment Conditions
2056
- env.prod: boolean;
2057
- env.dev: boolean;
2058
- env.build: boolean;
2059
- env.watch: boolean;
2060
- env.download: boolean;
2061
- env.upload: boolean;
2062
-
2063
- // Returns environment
2064
- util.env('dev' | 'prod'): boolean
2065
-
2066
- // Returns the current resource
2067
- util.mode('build' | 'watch' | 'upload' | 'download'): boolean
2068
-
2069
- // Returns spawns
2070
- util.spawned(): string[]
2071
-
2072
- ```
2073
-
2074
- # Contributing
2075
-
2076
- This project uses [pnpm](https://pnpm.js.org/en/cli/install). Fork the project, run `pnpm i` and you're good to go. If you're using Yarn like the rest of the plebs or npm then you will still need to install pnpm.
2077
-
2078
- # Author
2079
-
2080
- Created by [Nίκος Σαβίδης](https://github.com/panoply) of [Sissel ΣaaΣ](https://sissel.io).
2081
-
2082
- ### Acknowledgements
2083
-
2084
- Special thanks to a couple of talented developers that helped work through ideas and edge-cases on the project.
2085
-
2086
- - [Joseph Curtis](#)
2087
- - [David Warrington](https://ellodave.dev/)
2088
- - [Mansedan](#)
148
+ If you are an individual who would prefer to help financially, then please donate something to your local animal shelter and tell me about it on [X](https://x.com/niksavvidis). If you are a business, agency or acting on behalf of an enterprise then you can reach me via [email](mailto:n.savvidis@gmx.com) or message me on [X](https://x.com/niksavvidis).
2089
149
 
2090
- # Changelog
150
+ ### License
2091
151
 
2092
- Refer to the [Changelog](changelog.md) for each per-version update and/or fixes.
152
+ The project ships under [Apache License, Version 2.0](http://www.apache.org/licenses/LICENSE-2.0).