• Pull the title from the h1 of .md file
• Currently only using README.md in a dedicated directory is possible. Instead allow some-other-name.md

Restarting miyagi is necessary to show the changes.

Describe the bug
The documentation explains the --only parameters like this:

miyagi new <folderName>/<componentName> --only=tpl,docs

(https://docs.miyagi.dev/cli-commands/creating-a-component/#-only)

This only works if only one file type is specified (e.g. --only=tpl). If more than one file is specified (e.g. --only=tpl,docs) than the component folder will be empty.

Expected behavior
A component folder with all the specified files is created.

Additional context
The code expects the --only parameter to arrive as an array:

https://github.com/mgrsskls/miyagi/blob/dfcbf34f864398ce04d4388a9d6df951d1e54c72/packages/core/lib/generator/component.js#L64-L66

This only works for more than one file if multiple --onlys are specified like this:

miyagi new <folderName>/<componentName> --only=tpl --only=docs

Either allow adding a path to a file or add an example to the documentation how to use fs to read a file and use that in the config.

• Hide color and direction switcher behind settings icon? (Takes up too much space)
• Command palette?
• Link to docs
• Collapsable menu
• Show mock data also resolved

Is your feature request related to a problem? Please describe.
Problem is, when there are subcomponents layers deep, you have to open them all to see if any of them has invalid mock data.

Describe the solution you'd like
It would be nice if the parent component displays whether the child components have invalid mock data and gives a hint about that (preferably with the name of the affected subcomponent).

Describe alternatives you've considered
Maybe it is simpler done when this process can be started manually via a button?

Additional context

theme.mode could get another option called auto.

Idea

At the moment configuration files need to be created manually.

miyagi init should allow creating a configuration via cli (similar to vue cli e.g.).

Note for later: This could also be used for miyagi new

Open questions

What should exactly be configurable via cli

There are many options in the configuration. Should they all be configurable via CLI? Then there needs to be the possibility to skip certain sections.
If not every option should be configurable, which ones should be configurable then?

Is it possible to log more info if schema and mock don't match? Right now it's very difficult to find the erroneous definitions:
https://github.com/mgrsskls/miyagi/blob/8faf69cd4518d8f1fbb8c82fee81cc9b44fc789e/packages/core/lib/validator/mocks.js#L74

Idea

At the moment, all types of validation (mock data, mock data against schema, html, accessibility) only happen when a component is rendered in the component views.

Validations should be possible independently from rendering on

• miyagi start
• miyagi validate (using --skip and --only analogue to miyagi new)

Open questions

What happens when a file gets changed? Only revalidating that component is not sufficient as it might be included in other components (e.g. the html of other components would be affected). Do we need to revalidate all components?

Name and extension should not be configurable for docs

This is due to an incorrect date format.

As is: 2022-07-11 11:30:59Z
Should be: 2022-07-11T11:30:59Z

Describe the bug
Linting a single component always exits the process with code 0. Even when the component has invalid schema/mock data.

To Reproduce
Steps to reproduce the behavior:

1. Create invalid mock data for a component.
2. Lint this component with miyagi lint path/to/component.

Expected behavior
The process exits with error code 1 (like when linting all files with miyagi lint).

E.g. at the moment a component is rendered with a dark background even though a project might not support dark mode.

As I understand the docs getMergeMethod should be called with every variant.
However the function only gets called with root data.

Therefore this variant $opts gets ignored:

$opts:
  array_name: overwrite

See:

Link to docs:
https://docs.miyagi.dev/how-to/writing-mock-data/#merging-arrays

Describe the bug

The without filter from the package twig-drupal-filters is not working.

This happens because the without implementation from twig-drupal-filters uses all arguments after the first to select the keys to remove from the array (see filters/without.js#L26).

miyagi extends the without filter but doesn’t pass on the remaining arguments:

https://github.com/mgrsskls/miyagi/blob/fa451b269783c4f455c6ef70c01779a6f951a7e8/packages/twig-drupal/index.js#L149

To Reproduce

Steps to reproduce the behavior:

1. Create a new array like:

{% set test = { hello: "world", foo: "bar" } %}

2. Try to output the array without the hello key:

{{ dump(test|without("hello")) }}

3. The output is an empty array:

object(0) { }

Expected behavior

The output should be the original array without the hello key on the first level:

object(2) { [foo]=> string(3) "bar" [_keys]=> object(2) { [0]=> string(5) "hello" [1]=> string(3) "foo" } }

Idea

It would be nice to have a page, that renders colors, font sizes etc. to have something like a living styleguide, not only a component library.

This should happen completely by parsing CSS files to avoid any additional work for developers.

See https://holidaypirates.github.io/nucleus/demo e.g.

Implementation

What to include in the styleguide

• colors
  • text
  • background
  • border
• fonts
  • font-family
  • font-size
  • font-weight
  • line-height
  • text-transform
  • letter-spacing
• spacings

How to parse

Custom properties need to be defined in :root {} and need to start with a prefix like

• --color-
• --font-family-
• --font-size-
• --font-weight-
• --line-height-
• --text-transform-
• --letter-spacing-
• --spacing-

to be included in the styleguide. For later, customizing these via regexes might be an option, but for a first implementation, this is sufficient.

Everything after the prefix is used as the name, so primary would be the name for the color --color-primary.

Open questions

How to deal with media queries

Three options:

1. Using the original custom properties
   When using the original custom properties, we would simply render some elements and apply the custom properties. When doing that, the user would e.g. have to resize the window, change contrast settings of the OS etc.
   This makes the implementation very easy, but it does not give a full overview of the different custom properties. Especially e.g. colors, which can depend on some OS settings (prefers-contrast: high), would require manual changes by the user to see all variants.
2. Displaying the custom properties for each media query as defined
   This allows the user to see all variants by listing all media queries like an accordion and inside showing the custom properties, which are defined for that media query. This is easy to implement, but it does not show the user which custom properties are actually used for each media query (as it basically just mirrors the code which requires some mental effort).
3. Displaying the custom properties for each media query as computed
   This allows the user to see all variants at one glance, but it makes the implementation way more difficult.
   Media queries would be listed like an accordion and in each section, we would show the custom properties that would be active when this media query is active. The custom properties would not be used directly, but instead their parsed value.
   The difficult part is that custom properties do not exclusively belong to one media query, but can be used by multiple media queries. This is especially complicated when showing fonts, which is a combination of multiple properties. For example, this

:root {
  --font-family-body: Helvetica;
  --line-height: 1.4;
}
@media (max-width: 32em) {
  :root {
    --font-size-body: 1.6rem;
  }
}
@media (min-width: 32.03125em) {
  :root {
    --line-height: 1.6;
  }
}
@media (min-width: 32.03125em) and (max-width: 64em) {
  :root {
    --font-size-body: 1.8rem;
  }
}
@media (min-width: 64.03125em) {
  :root {
    --font-size-body: 2rem;
  }
}

would have to be displayed like this:

default:
  body:
    font-family: Helvetica
    line-height: 1.4
(max-width: 32em):
  body:
    font-family: Helvetica
    line-height: 1.4
    font-size: 1.6rem
(min-width: 32.03125em) and (max-width: 64em):
  body:
    font-family: Helvetica
    line-height: 1.6
    font-size: 1.8rem
(min-width: 64.03125em):
  body:
    font-family: Helvetica
    line-height: 1.6
    font-size: 2rem

Additionally it could for whatever reason happen that e.g. screen is used for just one media query. This would have to be considered as well.

Currently tending to solution 2.

How to deal with colors that are e.g. only for backgrounds

Depending on the design system, some colors might only be used for text and some might only be used for backgrounds, borders etc.
When scanning the CSS files for custom properties that start with --color-, there is no way to know if it should be used for text or backgrounds or both.

Idea:
Custom properties can start with --color-text- (or simply --color-text: in that case text would be the name and it would be clear that it is for text), --color-bg-, --color-border-etc.. That way it would be clear what it is used for. What happens though if there are also custom properties, that only start with--color-`? Should they be displayed for text, background, border etc.?

What to do with custom properties that have a custom property as value

Example:

:root {
  --color-black: #000;
  --color-mediumGrey: #999;
  --color-text: var(--color-mediumGrey);
}

@media (prefers-contrast: high) {
  --color-text: var(--color-black);
}

Should the custom property --color-text be ignored as its values have actually already been display before?
If we display it, should it be labelled by the defined value (--color-mediumGrey and --color-black) or the computed values (#999 and #000)?
If we display it, should we use the actual custom property or the computed value to display the color? Probably the computed value, as this would be in sync with how we would most likely deal with media queries.

Describe the bug
If there is a README.md inside the component's directory, it gets rendered on top of the component's view in miyagi. The word wrapping is not correct.

To Reproduce
Steps to reproduce the behavior:

1. open a miyagi instance on e.g. localhost:5000
2. If there is a top-level readme in place, you can see the word-wrapping is not right
3. Create a readme somewhere with a longer text of line, ake sure it doesnt accidentally break at a whitespace anyway.
4. See error

Expected behavior
Proper word wrapping at end of line

Screenshots
.

Desktop (please complete the following information):

• OS: [e.g. iOS] Kubuntu
• Browser [e.g. chrome, safari] Firefox
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22] 115.0.2

Additional context

Idea

With the next release, the content of the mock file will be rendered on the component view.

Additionally iIt would be nice to show the computed mock data for each variation.

Implementation

Should be rendered on

• the variant view (next to the "Open in new tab" link)
• the component view (next to the "Open in new tab" link)

as link that opens a modal.

Describe the bug
The command miyagi new folder/component only works with Yarn.

To Reproduce
Steps to reproduce the behavior:

1. cd to root folder of a miyagi project.
2. Execute e.g. node node_modules/.bin/miyagi new test

Expected behavior
A new miyagi component is created.

Additional context
The issue is most likely the use of the environment variable process.env.INIT_CWD in these two places:

https://github.com/mgrsskls/miyagi/blob/74d0b81c1206f1fd41b71e9990490db1bde8a8c3/packages/core/lib/generator/component.js#L156

https://github.com/mgrsskls/miyagi/blob/74d0b81c1206f1fd41b71e9990490db1bde8a8c3/packages/core/lib/generator/component.js#L233

This variable is only available when running a script with Yarn. Node.js/npm don’t set this variable.

Is your feature request related to a problem? Please describe.
The problem is, in big clunky schema/mocks.yaml's, it is sometimes a bit hard to find the mistyped or misplaced property.

Describe the solution you'd like
In console, instead of:

2023/07/07 15:22 Error: template-components/header — default:
data must NOT have additional properties

I'd like an additional piece of text with the name/key of the invalid mock data, and maybe the parent properties, to see where it sits (often there are a lot of properties with same name, like url).
Similarly for the error message in the web frontend which just says Invalid mock data.

Describe alternatives you've considered
None, I figured if there is a comparison check between allowed keys (schema) and provided keys (mocks), the ones causing the differences should be on display somehow.

Additional context

At the moment a directory that does not have a template file, is rendered in the menu, but not linked. That is because components were supposed to always have a template file. But it might e.g. also be good to render some CSS helpers. Therefore a component should be rendered as soon as any of the following files is available:

• template
• assets (css, js)
• docs

Prerequisite: #9

Implementation

• The template is already rendered on the component view, but CSS and JS files would need to be added to the files tabs.
• Variation views should not be created

Open questions

Should mocks be shown in the files tabs? They do not make sense without a template file.

Describe the bug
miyagi can’t create the directory tree structure when the project folder’s path contains strings that are matched by the ignore/exclude regexes for directory-tree.

To Reproduce
Steps to reproduce the behavior:

1. Create a miyagi project in a folder whose path contains git (e.g. github or gitlab).
2. Start miyagi either with miyagi start or miyagi build.
3. See error message:

Error: The provided components directory 'whatever' does not seem to exist. You can specify this in your config file (key: 'components.folder', type: String) or as a cli argument (--components.folder=<String>).

Expected behavior
The projects works as usual since the components folder exists.

Additional context
The following code…

…produces regexes that look like this:

[
  /node_modules/,
  /.git/,
  /package.json/,
  /package-lock.json/,
  /.miyagi.js/,
  /.miyagi.json/
]

Note: The . in the file names isn’t escaped which creates overly broad exclude patterns.

• One config file per brand, inheriting from main config file (e.g. .miyagi.js, .miyagi.brand1.js, .miyagi.brand2.js). This allows different theming of miyagi itself as well as different CSS files etc for the actual project.
• A brand switch in the miyagi UI which toggles the brand on-the-fly
• miyagi build would create a build including all brands, miyagi build --brand <brand> would create a build without the switch

The term brand is just temporarily, should probably be changed.

Describe the bug

Opening any page that runs axe results in a Maximum call stack size exceeded error after a few seconds. This problem only occurs in Chromium and WebKit. Firefox seems to be unaffected.

This also also prevents the "Accessibility" hints section not being rendered.

To Reproduce

Steps to reproduce the behavior:

1. Clone the minimal reproduction repository: https://github.com/mvsde/miyagi-minimal
2. Follow the readme steps to install and start the project.
3. Visit http://localhost:5000/show?file=hello-world&variation=default in a Chromium or WebKit browser.
4. Wait a few seconds until the browser stops the call stack and throws an error in the console.

Expected behavior

The call stack size isn't exceeded and the "Accessibility" hints section is rendered above the "HTML" validation section.

Screenshots

Chromium:

WebKit:

Browser

• OS: Fedora 34
• Browser: Google Chrome 94.0.4606.71 and GNOME Web 41.0 (based on WebKit)

If the background if the sidebar is set to something dark and the color to something bright, the text for the validations is also bright (on a possibly bright background).

The color for the validations should be the same as the one for the iframe.

The whole content area is rendered inside an iframe, not only the actual component. That means that there is spacing as well as other content around the component. This might cause the component to be rendered differently than it is actually supposed to when using media queries (as styling is not completely intrinsic then).

This is fine for small components like buttons, but could be problematic for more complex components.

Currently only the schema file is rendered on the component view. Following files should be rendered as well:

• template
• mocks

When running miyagi start with node 14, I get the following error: Error: Cannot find module 'chalk'.
It works with other node versions and it works when using yarn miyagi start.

Describe the bug
When executing Miyagi commands via cli, the dates that accompany status messages appear to be off by one month

To Reproduce

1. run yarn start:cl
2. each status message displays the date, but it is off by one month

Expected behavior
The status message displays the correct date

Screenshots

Idea

At the moment, mock files can only be of one type (defined in the configuration). But having different file types could be useful when by default yaml e.g. should be used, but asynchronous mock data is also necessary.

Implementation

Instead of only searching for files based on the configuration, miyagi should look for all files named mocks (or whatever is defined in the configuration) with an extension of either js, json or yaml.
The default mock type should be kept for generating new components using miyagi new.

Describe the bug
When a component folder is named as if it was a file, miyagi tries to read the folder as a file.

To reproduce
Steps to reproduce the behavior:

1. Go into the components directory of a miyagi project.
2. Create a new folder with a template “file extension”, e.g. header.twig.
3. A similar problem occurs with folders named after mock and schema files, e.g. mocks.yaml or schema.yaml.

Expected behavior
While traversing folders and files, miyagi shouldn’t try to ingest folders as files.

Error messages
Error message for folders named like template files:

node:fs:759
  handleErrorFromBinding(ctx);
  ^

Error: EISDIR: illegal operation on a directory, read
    at Object.readSync (node:fs:759:3)
    at tryReadSync (node:fs:440:20)
    at Object.readFileSync (node:fs:486:19)
    at readFile (/path/to/project/node_modules/@miyagi/core/lib/state/file-contents.js:190:17)
    at /path/to/project/node_modules/@miyagi/core/lib/init/watcher.js:83:13
    at new Promise (<anonymous>)
    at updateFileContents (/path/to/project/node_modules/@miyagi/core/lib/init/watcher.js:82:11)
    at handleFileChange (/path/to/project/node_modules/@miyagi/core/lib/init/watcher.js:188:29)
    at Timeout._onTimeout (/path/to/project/node_modules/@miyagi/core/lib/init/watcher.js:350:11)
    at listOnTimeout (node:internal/timers:573:17)
    at process.processTimers (node:internal/timers:514:7) {
  errno: -21,
  syscall: 'read',
  code: 'EISDIR'
}

Node.js v20.2.0

Error message for folders named like mock and schema files:

Warning: It seems like the file path/to/component/mocks.yaml has an invalid format as miyagi was not able to parse it.

Integrating html-validate could be useful. On the other hand, this should maybe also just be part of the developer's linting.

Prepending 01-, 02- etc. to a directory name is often used to sort them.

Implementation

• Remove 01-, 02- etc. from directory names here:
  • menu
  • URLs in dev environment
  • URLs in build environment
  • breadcrumb links
• Preserve order

Describe the bug
When a js file is added with the following configuration, there are missing spaces between attributes

To Reproduce
Steps to reproduce the behavior:

1. add js file with this configuration

    {
      src: "assets/js/index.js",
      type: "module",
      defer: true,
    },

2. this script gets added

<script src="assets/js/index.js" type="module"defer></script>

Expected behavior
There should be a space between every attribute.

<script src="build/assets/js/index.js" type="module" defer></script>

Describe the bug
The dist folder is missing in the 3.4.8 release on npm.

To Reproduce
Steps to reproduce the behavior:

1. Go to the npm code page for miyagi
2. There is no dist folder

Expected behavior
The release includes the dist folder.