You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the previous assemble / stylemark setup, component markup were generated twice, once in the components/ folder and once in lsg_components/ with optionally different setup, this included different templates (lsgTemplatesSrc vs. lsgTemplatesSrc) and different data (any data file in the layouts folder (cdTemplatesSrc) were only applied when the components/ markup was generated).
after the new stylemark implementation, same markup is used for components/ and also in styleguide/. The issue with that is that any relative paths can only work in one output. But there is use cases for both outputs, styleguide/ as the living styleguide and components/ for example for testing.
To fix this, a solution can be to generate the styleguide output with the same folder structure as the html that are read from target/components/ folder.
e.g. for foo/bar.md's ```html example-1 ./demo/test1.html the markup file will be created as styleguide/foo/demo/bar-example-1.html instead of styleguide/bar-example-1.html.
This ensures that the html files have the same depth in both components/ and styleguide/
The other thing is that having data files in the layout directory that are only applied to the compotes output and not pages is not intuitive. assemble-lite also does not support any data in form of yamel front matter in the layout hbs files themselves. currently there isn't any lsg layout folder anymore, so to distinguish between component data and pages data, it would make more sense to allow data files in the pages/ folder that are only applied to the pages when they are generated. and not to the components. This way still it would be possible to provide for example different pathPrefix to pages and component as it was before, with the difference that the default data will be then in the components/ and the pages/ can overwrite it with its data.
The text was updated successfully, but these errors were encountered:
…s in components/
this will allow same relative paths in the html to work in both scenarios (directly in componets
e.g. for tests and in styleguide)
re #237
In the previous assemble / stylemark setup, component markup were generated twice, once in the
components/
folder and once inlsg_components/
with optionally different setup, this included different templates (lsgTemplatesSrc
vs.lsgTemplatesSrc
) and different data (any data file in the layouts folder (cdTemplatesSrc
) were only applied when thecomponents/
markup was generated).after the new stylemark implementation, same markup is used for
components/
and also instyleguide/
. The issue with that is that any relative paths can only work in one output. But there is use cases for both outputs,styleguide/
as the living styleguide andcomponents/
for example for testing.To fix this, a solution can be to generate the styleguide output with the same folder structure as the html that are read from
target/components/
folder.e.g. for
foo/bar.md
's```html example-1 ./demo/test1.html
the markup file will be created asstyleguide/foo/demo/bar-example-1.html
instead ofstyleguide/bar-example-1.html
.This ensures that the html files have the same depth in both
components/
andstyleguide/
The other thing is that having data files in the layout directory that are only applied to the compotes output and not pages is not intuitive. assemble-lite also does not support any data in form of yamel front matter in the layout hbs files themselves. currently there isn't any lsg layout folder anymore, so to distinguish between component data and pages data, it would make more sense to allow data files in the
pages/
folder that are only applied to the pages when they are generated. and not to the components. This way still it would be possible to provide for example differentpathPrefix
to pages and component as it was before, with the difference that the default data will be then in the components/ and the pages/ can overwrite it with its data.The text was updated successfully, but these errors were encountered: