TBD whether or not this is worth doing for 1.0.0 (largely depends on the status of ubuntu for Windows)

• normalization for OS paths, any other code changes required
• testing with powershell or other common windows terminal environments.

this repo will be an npm package.

Problem

Error: ENOENT: no such file or directory, open 'config.yml'

It throws an error. Ideally this should just say it needs a config.yml

Problem

slate build generates error on line 97 of index.js when using nodejs 8.x
if (!require.extensions.hasOwnProperty(ext)) {

Scope

slate command on systems with nodejs 8.x or higher installs

Replication steps

Install slate and slate-tools on a system with nodejs 8.x

More Information

It appears this issue is related to the removal of require.extensions from nodejs 8.

According to this answer on StackOverflow:
https://stackoverflow.com/a/44301178

require.extensions was deprecated in nodejs v0.10.6, but not dropped from the nodejs codebase until nodejs 8.0.
https://nodejs.org/api/globals.html#globals_require_extensions

potentially roll this into slate -v (or add a separate command to get this).

This is a pretty important requirement for debugging.

Problem

slate watch fails randomly after x minutes of normal operation with the error Unhandled 'error' event

Replication steps

There are really none I can state other than using slate watch

More Information

I am using Windows 10 x64 (latest stable)
WebStorm (latest stable)
Node 6.11.0 (latest lts)

See the attached txt doc for console output that shows the issue.

Thanks!!

console-log.txt

Every local change while slate is watching, triggers the theme upload of the file successfully, then detects change in .DS_Store, tries to run theme upload on that file and then gets hung there, staying at 0%

Tried adding DS_Store to ignore files and has no effect

ignore_files:
- "*.DS_Store"

If you're outside a theme directory and you evoke the help function, you're presented with the following:

While, inside a theme directory you get this:

A few things about this seem problematic to me:

1. The red x makes it feel like an error when you're not in a theme directory. Has something gone wrong with my Slate install?
2. The message is not clear around why you're getting this message (it tells you how to fix it, but not why it's appearing).
3. When you're inside a theme directory, it's confusing that you're getting a validation check, again without the context of why.

@macdonaldr93 @Shopify/themes-fed

Steps to reproduce:

1. Run slate start without a theme_id specified in config.yml
2. Choose Y when prompted about overwriting theme.

Seems to hang here forever @Shopify/themes-fed

Right now if you run a slate command from a non-slate folder, you end up with a confusing gulp error, would be great if we could let the user know they need to run this from inside their theme directory with a nice little message.

slate new theme tester fails after you answer n to Will you be tracking this theme in git?

 >> slate new theme tester
? Will you be deploying this theme to multiple environments? No
? Will you be tracking this theme in git? No
Unknown scaffold, please use one of the following scaffolds:
 slate

events.js:154
      throw er; // Unhandled 'error' event
      ^
AssertionError: Trying to copy from a source that does not exist: /Users/carsonshold/Documents/Projects/slate-cli/node_modules/Slate/generators/config.yml.ejs

@macdonaldr93 @m-ux

Suggestion for enhancement

Currently, a user should first run slate migrate, then download and configure https://github.com/Shopify/slate/blob/master/config-sample.yml into their root. We could streamline this experience by generating this file as part of the migrate task, and then modify the complete message
to instruct the user to modify the contents.

We need to add a requirements section - with info around what version of node is required, and other requirements.

ie. git

(anything else that is a requirement should be listed as well).

When using the slate new theme generator, odds are that the user hasn't yet set up a remote repository.

If a user generates a slate theme, then tries to run a deploy command they get the following error:

Let's clean this up and present something more instructional & user friendly.

@macdonaldr93 @Shopify/themes-fed

Problem

I've got three environments set up, Development, Staging, and Production. The Production environment is live.

When I use one of the Sync Commands [deploy, watch, start] on either Development or Staging environments, The browser window that automatically opens up at https://localhost:3000, my 'live' Production environment.

Which leads to the issue, when I make changes, BrowserSync refreshes the page, but obviously I can't see any changes because it is displaying the wrong environment.

Scope

Not sure, but probably related to how themekit interacts with BrowserSync.

Replication steps

Node v6.7.0
NPM v3.10.7
Slate v0.9.1

nothing special in my config.yml:

---
development:
password: THEMEKIT_PASSWORD
theme_id: "163808707"
store: THEMEKIT_STORE
ignore_files:
- config/settings_data.json
staging:
password: THEMEKIT_PASSWORD
theme_id: "163824835"
store: THEMEKIT_STORE
ignore_files:
- config/settings_data.json
production:
password: THEMEKIT_PASSWORD
theme_id: "162599811"
store: THEMEKIT_STORE
ignore_files:
- config/settings_data.json

More Information

Usually when one views an unpublished theme there is a url param.
it should be something like this, right?

https://localhost:3000/?key=3479939321d9d4d43f0ff418f9ed258ee6a4260e61c89608d4eb17199ae9d34c&preview_theme_id=163808707

These are my Access URLs:

      Local: https://localhost:3000
      External: https://10.1.10.74:3000

      UI: http://localhost:3001
      UI External: http://10.1.10.74:3001

Just noticed that slate theme still has characters such as ✓. These should have been changed over to use the figures package for cross-OS support. figures.tick should be used.

\cc @NathanPJF

What the title says.

Browsersync's localhost proxy is running on https:// but we don't have a signed certificate.

we should be able to get around this using an appropriate npm module.

See @richgilbank for more info if necessary.

Problem

It does not seem to be possible to import a sass file from the node_modules which have some dependencies.

Scope

Issue related to slate-watch.

Replication steps

In theme.scss:

@import url('../../node_modules/lib-a/scss/lib-a.scss');

In lib-a.scss:

@import '../_vendor/lib-b/sass/lib-b';

Error when using slate watch:

[10:47:05] change in src/styles - change theme.scss
[10:47:05] running task - build:css
[10:47:05] Error in plugin 'gulp-cssimport'
Message:
    Cannot find file '../_vendor/lib-b/sass/lib-b' from 
    '/[project-path]/node_modules/lib-a/scss' (includePaths: )

More Information

It could be caused by the result of this logic:
https://github.com/Shopify/slate/blob/master/docs/theme-scaffold/index.md#sass-helpers
The tool is uploading local SCSS files, not compiling them. This might cause an issue with files from node_modules?

What would be the workaround?

Received a promise reject which wasn't handled by await.

Once I've initialized a new theme using slate new theme, my options are

1. Provide a theme_id option for ThemeKit (http://themekit.cat/docs/ doesn't mention where to actually get it, I copied it from the URL of the HTML editor)
2. Replace the active theme on my shop

I would assume the sensible option is to create a new theme on my shop and store that id in my config.yml.

I believe we're just copying over https://github.com/Shopify/slate/blob/master/LICENSE.

On a deploy command ( along with issue #95 ) we output verbost themekit instructions on how to properly call the underlying themekit command (which doesn't help a slate user, and potentially adds confusion to the issue).

Is there a way we can turn logging off for themekit commands?

Problem

I'd really like to bring Slate CLI into my workplace, but we use BitBucket here to work collab so the typical build & upload to Shopify wouldn't be suitable.

Would it be possible to somehow have it push to BitBucket before being deployed?

Problem

When downloading an existing theme from a store, the contents of /config will be compressed, reducing their readability. It would be great if as part of the migrate command, these files could be uncompressed, to make them easy to work with.

Scope

Most visible as part of slate migrate, but may involve modification to slate-tools.

Replication steps

1. Download an existing theme from Shopify
2. Open config/settings_data.json

More Information

Current workaround during dev is to open the settings_*.json files in the admin-based web editor for the theme you're working on, where they'll be shown uncompressed, and copy/paste into your local versions of those files.

It appears the UTF-8 characters are not displaying in powershell.

Problem

slate theme uses npm install - and yarn can speed up this installation process for some users.

Scope

Just slate theme - as far as I know.

These sections / .md files must be added to the slate-cli github repository prior to public release.

Goal: Prevent dangerous connection error on browsersync proxy.

http://shopify.github.io/themekit/docs#config-variables doesn't exist anymore.

We should probably update the content in config-sample.yml to make sure we're sending people to the appropriate resource.

Problem

I've run into an issue several times today using slate start on some of Shopify's themes.

The CSS sometimes has different values for fonts, colours, etc. These values didn't correspond to any values in existing presets in the theme I was building at the time.

The issue looks like this (this example is using Simple):

Here's a diffcheck of the uglified CSS for each of the above instances.

It could be that values from settings_data.json from the previous theme are being used/not replaced correctly.

Scope

I only saw it while running slate start, but haven't tried to reproduce using slate deploy on its own for example.

Replication steps

1. Use slate's tools to deploy a theme to a test store.
2. Use slate start to build and deploy a second, different Shopify theme to the same theme_id on the same store.
3. Inspect the contents of the main CSS file and compare it with the expected contents.

Problem

Every time I save a file it fails to upload it. I am met with the error:

[15:24:54] change in src/sections - change product.liquid
[15:24:54] running task - build:assets
[15:24:54] sections/product.liquid 4.8 kB
[15:24:54] change in sections - change product.liquid
[15:24:54] Initiating deploy to development
[15:24:55] running task [child process] - theme upload
[15:24:55] Transfer Failed: File(s) failed to upload to store. See log notes above.
[15:24:55] change in src/sections - change product.liquid
[15:24:55] running task - build:assets
[15:24:56] sections/product.liquid 4.8 kB
[15:24:56] change in sections - change product.liquid
[15:24:56] Initiating deploy to development
[15:24:56] running task [child process] - theme upload
[15:24:56] Transfer Failed: File(s) failed to upload to store. See log notes above.

Scope

While the error occurs due to something probably wrong in my theme files, the error message is probably something that should be fixed in the slate-cli.

It says "See log notes above." on the last line however there are no helpful log notes as to what failed or why it failed.

Replication steps

This problem occurred after I created a git repo of my theme and pushed all the files to git. I've tried ignoring all .git/ files via the config.yml but the issue persists. Possibly not related to git?

Problem

There is a reported issue with Slate where requireDir fails on Node v8. Shopify/slate#170

/Users/justin/Sites/Shopify/theme-name/node_modules/require-dir/index.js:97
            if (!require.extensions.hasOwnProperty(ext)) {
                                    ^

TypeError: require.extensions.hasOwnProperty is not a function
    at requireDir (/Users/justin/Sites/Shopify/theme-name/node_modules/require-dir/index.js:97:37)
    at Object.<anonymous> (/Users/justin/Sites/Shopify/augies-shopify/node_modules/@shopify/slate-tools/lib/gulpfile.js:39:1)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Module.require (module.js:513:17)
    at require (internal/module.js:11:18)
    at Liftoff.handleArguments (/Users/justin/Sites/Shopify/augies-shopify/node_modules/gulp/bin/gulp.js:116:3)

Scope

This is related to all commands for Slate. slate watch, slate start, and state zip.

Replication steps

1. Upgrade to Node v8.0.0 and NPM 5.0.1
2. Clean install Slate CLI npm install -g @shopify/slate
3. Initialize a new theme using Slate slate theme new-theme
4. Run slate watch or slate start or slate zip
5. Error occurs

More Information

Reference issue first referenced under Slate repo

the following is difficult to parse/read:

Is there anything we can do about the formatting at the commander level? If not, I would suggest not using short forms for our primary commands, and limiting them to options / args.