• --install — to install dependencies or not
• --git — init fir repo:
  • init repo;
  • create .gitignore:
  • add repo info to package.json:
  • if there is a link to the remote repository, insert it into the badge Fork me on GitHub.

Now I just download publicly available `shower ' for every new project.zip ' and unpack it to the desired folder.

This mechanism has 3 big problems:

1. The format of the `.zip ' hard and long to unpack inside node
2. You cannot find the version of the template, and this prevents it from being cached
3. You cannot verify the integrity of a downloaded or cached template

To solve this one would be:

1. To collect not only zip but a tar archive. Node has powerful tools for working with tar archives.
2. Generate and put next to `meta ' files.json ' in which to specify the template version, checksum and any other information. This allowed to create a caching tool (taking into account the cache update to new versions), and also to check that the download was correct

During the creation of a new presentation, the CLI automatically sets the dependencies. You need to ask the user if they want to install dependencies now.

If you choose not to install dependencies, you still need to add them to the package.json.

For example, eslint-cli works on initialization.

Since version 2.0 the main functions are implemented: create, archive, prepare, save, publish and pdf. Each of these functions can be configured, for example, for prepare, you can specify the folder in which the project will be built and for pdf file name. Now these parameters are set by default and can be overridden by flags. But it's not flexible enough. What if I want a pdf file always called best_press.pdf or rename index.html in presentation.html?

The second problem is that some functionality is not needed by everyone, but would be useful in the form of plugins, such as code highlighting

I propose to look at the solution from webpack@4 and implement a configuration file for presentations, as shower.config.js. In order not to overcomplicate projects, if the config is not set, the default settings will be used, but if additional features are required, the user can flexibly configure the project.

It supposed to be 4/3. And I’d rather list it as 4:3 and 16:9, as it’s a bit more commonly used.

Now the work of tasks is tested manually before publishing a new version. To avoid regression and broken releases, acceptance tests are needed for all tickets.l

Steps to reproduce:

shower create
cd slides
shower prepare

Output:

events.js:167
      throw er; // Unhandled 'error' event
      ^

Error: File not found with singular glob: /Users/pepelsbey/Desktop/slides/node_modules/shower-lib/shower.min.js (if this was purposeful, use `allowEmpty` option)
    at Glob.<anonymous> (/Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/glob-stream/readable.js:84:17)
    at Object.onceWrapper (events.js:273:13)
    at Glob.emit (events.js:182:13)
    at Glob._finish (/Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/glob/glob.js:197:8)
    at done (/Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/glob/glob.js:182:14)
    at Glob._processSimple2 (/Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/glob/glob.js:688:12)
    at /Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/glob/glob.js:676:10
    at Glob._stat2 (/Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/glob/glob.js:772:12)
    at lstatcb_ (/Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/glob/glob.js:764:12)
    at RES (/Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/inflight/inflight.js:31:16)
Emitted 'error' event at:
    at Pumpify.emit (events.js:182:13)
    at Pumpify.Duplexify._destroy (/Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/duplexify/index.js:191:15)
    at /Users/pepelsbey/.nvm/versions/node/v10.11.0/lib/node_modules/shower-cli/node_modules/duplexify/index.js:182:10
    at process._tickCallback (internal/process/next_tick.js:61:11)

Maybe we should have some tests that would run and check basic functions before allowing project to be published to npm? Otherwise it breaks too often and it’s hard to rely on such tool :(

When I publish theme updates with np utility, it runs tests first. It allows updates to be published to npm only if they pass.

My suggestion is dealing with an issue to run commands in terminal without any steps to setup slides.

Shower CLI is pretty good interface to create and manage a presentation! I was absolutely happy with this tool any time before. But...

I want to build up a new layer under Shower CLI. It will be an extension for VS Code for managing a presentation in this IDE. I want to use Shower CLI for commands but it is impossible. I'll try to describe on an example of one command for clarification. Command shower create is constructed as a master for own settings and fast command for default settings. It will be much more relevant to my case if shower create will be able to setup theme and ratio via parameters, e.g. --theme and --ratio. It will be suitable for any cases are connected with bash scripts and any high-level tools based on Shower CLI as my own.

I will be happy to become a contributor to make this feature. Also I'm thinking seriously about support of any other repository's issues in the list. I'm trying to be useful.

Is it possible to answer me on suggestion which I've described above?

@nikolay-govorov @pepelsbey

The main idea is to add auto end-to-end tests for all commands in CLI.
@nikolay-govorov @pepelsbey

I installed the shower-cli and shower globally. When I want to create a presentation by shower create it doesn't happen.

Other commands have the same
PowerShell has the same as cmd

Just like many CLI tools do: grunt-cli becomes grunt, the same applies to Gulp and many others. It’s much easier to type shower instead of shower-cli.

Steps to reproduce:

1. shower create semantics
2. Wait…
3. shower create semantics
4. Do you want to overwrite it? Yes

~/Documents/Пепелсбей.net/Сайт/pres
$ shower create semantics
? The semantics dir already exists. Do you want to overwrite it? Yes
shower create [<directory>]

- Create a new project

Positionals:
  directory

Options:
  --help     Show help                                                 [boolean]
  --version  Show version number                                       [boolean]

Error: Cannot delete files/folders outside the current working directory. Can be overriden with the `force` option.
    at safeCheck (/Users/pepelsbey/.nvm/versions/node/v10.10.0/lib/node_modules/shower-cli/node_modules/del/index.js:18:9)
    at mapper (/Users/pepelsbey/.nvm/versions/node/v10.10.0/lib/node_modules/shower-cli/node_modules/del/index.js:33:4)
    at Promise.resolve.then.el (/Users/pepelsbey/.nvm/versions/node/v10.10.0/lib/node_modules/shower-cli/node_modules/p-map/index.js:46:16)

I doubt anyone needs BrowserSync’s UI page and “Browsersync: connected” message every time page opens or reloads. Options to disable:

ui: false,
notify: false

It’s different from the one used in shower-core’s JS, shower’s and theme’s HTML. Mostly it’s 2 spaces vs. 4 spaces difference, but HTML is also formatted in a different way.

I’d keep it consistent throughout the whole project, if you don’t mind. Because now when I run shower create I see your code style, not Shower’s one.

It’s much easier to control what goes to the package if you specifically include files, not exclude everything, but…

See example in @shower/core.

…if there’s an empty or unrecognized command passed. Just like all good utils do instead of blaming you for something. In the future it should become a short version of help command, more on that in a separate issue.

Hi, I try to use shower cli to create a new slides, however it stuck there and my cpu goes to 100% for the @shower/cli process.

Here's the debug:

➜ node -v
v14.2.0

➜ npm -v
6.14.4

➜ yarn -v
1.22.4

➜ NODE_DEBUG=* shower create a
...
ESM 84649: Storing file:///Users/user/.config/yarn/global/node_modules/execa/lib/command.js in ModuleMap
ESM 84649: Storing file:///Users/user/.config/yarn/global/node_modules/execa/index.js in ModuleMap
ESM 84649: Storing file:///Users/user/.config/yarn/global/node_modules/@shower/cli/core/lib/npm.js in ModuleMap
ESM 84649: Storing file:///Users/user/.config/yarn/global/node_modules/@shower/cli/core/command/create.js in ModuleMap

Do you have any idea what might went wrong here?

page.pdf({ path: file, width: '960px', height: '600px' }))

It used to be 1024×640 (16:10) according to @page rule, so it wasn’t already the right one. But since Ribbon 3.0 and Material 2.0 are 16:9 by default, meaning 1024×576. But it also could be changed to 1024×768 (4:3), 1024×1024 (1:1) or any other ratio and it should be somehow detected by printing script. There are --slide-width and --slide-ratio variables available on .shower element.

Currently, it produces white bars:

I suggest we should detect current slide size before printing it.

pkg have engines but not process.
Either pkg, either process should be removed.

Something like this:

<!DOCTYPE html>
<html lang="<%= lang %>">

It’s important to have a proper language set.

Configure Travis to run tests on Linux, Windows and macOS

Can we use shorter command for creating new slides?

npx shower/cli create my-slides

Inspired by CRA

Currently the only entry point for CLI is the index.html. In my case I often have multiple versions of my slides:

andersen.html
codefest.html
fwdays.html
yandex.html

It would be good if CLI could do the following:

• Look for *.(html|htm) file in the root
• If there’s only one found, just print PDF with the name of this file: index.pdf, not presentation.pdf like it does right now. You don’t expect presentation name because you don’t use it anywhere.
• If there are multiple files, list all of them and ask which one to print, just like it does for the themes.

@nikolay-govorov what do you think?

Can we add here the possibility of creating themes?

It would be good to have common JS code style throughout the whole organization.

If you don’t mind, I’d suggest using ; and 4 spaces, just like we do in .eslintrc.yml of shower-core, the main code base of the Shower project. It’s basically airbnb-base with some extras. The same, but in a form if .editorconfig and .stylelintrc exists in both themes.

We can always discuss details, but having a common code style is essential for a project like this.

Why do you hardcode it?
but this version of ${pkg.name} requires Node ${chalk.bold(pkg.engines.node)}.\n — do it like this.
Hardcode is bad practice.

Currently the tools itself contains a template with a single slide. It doesn’t work already for the Material theme that contains some special markup for the badge:

<footer class="badge">
  <a href="https://github.com/shower/shower">
  <svg width="81" height="79" viewBox="0 0 81 79" aria-hidden="true">
    <path d="M40.5 0a40.5 40.5 0 0 0-12.8 78.93c2 .37 2.76-.88 2.76-2s0-3.51-.05-6.89c-11.27 2.45-13.64-5.43-13.64-5.43-1.84-4.68-4.5-5.92-4.5-5.92-3.68-2.51.28-2.46.28-2.46 4.06.29 6.2 4.17 6.2 4.17 3.61 6.19 9.48 4.4 11.79 3.37a8.65 8.65 0 0 1 2.57-5.41c-9-1-18.45-4.5-18.45-20a15.65 15.65 0 0 1 4.17-10.87 14.57 14.57 0 0 1 .4-10.72s3.4-1.09 11.14 4.15a38.39 38.39 0 0 1 20.28 0c7.73-5.24 11.13-4.15 11.13-4.15a14.55 14.55 0 0 1 .4 10.72 15.63 15.63 0 0 1 4.16 10.87c0 15.56-9.47 19-18.49 20 1.45 1.25 2.75 3.72 2.75 7.5v11.11c0 1.08.73 2.34 2.78 1.95A40.51 40.51 0 0 0 40.5 0z"/>
  </svg>
  Fork me<br>on GitHub
  </a>
</footer>

Unfortunately it’s not Zen Garden and everything couldn’t be achieved only via CSS.

Also a lot of people are not aware of built-in features and giving all of them by default would really help.

We’re in the process of moving packages from shower-package to @shower/package structure. The latest theme releases are already published exclusively to @shower/ribbon and @shower/material. Shower’s gulpfile is also got updated accordingly to prepare && archive properly.

I guess shower-cli needs the same update.

The main volume is @shower/cli. We can add the ability to use globally installed @shower/cli from the presentation, and locally put only theme/core and the like.

Originally posted by @nikolay-govorov in shower/shower#349 (comment)

To avoid fail, you should publish packages from CI. For example, it can be semantic-release or np

I need help. I speak English rather badly, and it is necessary to check whether I have made mistakes in the documentation or reference information.

In the basic shower/cli template, the "prepare" command is added, which turns out to be reserved in npm: https://docs.npmjs.com/misc/scripts.

This command will be called before installing the dependencies, and since shower is not yet installed the installation will break.

You need to rename the NPM script to build or package so that it is not called when you install dependencies.