xfiveco / generator-chisel Goto Github PK

xfiveco/generator-xh#122

This is a followup on a discussion we had.

We agreed that, since we're staying with our current folder structure (src at project root, regardless front-end or WP project type), it would be nice to have a guide explaining briefly how developers can move all front-end source files to WP theme folder, so one could edit all src files in one place.

Example:

Setup:

• Node v5.11.0
• NPM 3.8.8
• Yo 1.8.4
• generator-chisel 0.1.2

Is it me or something is wrong?

I've found an issue while adding pngs to a repo and pushing to gitlab.
It treats pngs like a text files and probably alters their eol.
If you add *.png binary to .gitattributes, problem is solved.

Generating WP project will involve things like:

• install WordPress & Timber
• create theme folder from name-slug
• copy template files to the theme folder
• copy Timber base theme files
• remove Gulp templates task (as Twig templates are supported by Timber)
• add custom assetPath function to Twig to load default or revisioned styles/scripts, decide when to load which one (proxy test?)
• do not create project index when running page subgenerator
• allow custom wp-config and other setup
• adjust coding style to codex (tabs?)

What should I do to take a look at a default page?

After running gulp I see:

Meanwhile in our XH generator it looks like this:

I'm not sure If I should take some additional action after yo chisel?

Hey,

I'm in the middle of project development for client using Chisel and so far I've been running into many problems with code style.
At one point I even discovered some rules that contradict each other (requiring single quotes and enforcing double quotes on font names at the same time).
Stylelint seems to be really strict (as opposed to scss_lint which has sane defaults).
Perhaps we could consider tweaking our settings or using some external config with few overrides?
Seems like https://github.com/stylelint/stylelint-config-standard is the most popular one right now.

I'd love our linter to nugde me in the right direction, without being too dogmatic at the same time...
Is there a way to define some rules that would warn, but not err?

Curious about your feedback.

D.

Currently all templates are stored (or rather buried) in generators/app/templates. This makes them less obvious and only accessible for the main generator.

Using template context we could move all templates to the root folder so they are easier to maintain and other sub generators can use them as well.

Something like this works, though probably it could be refactored to a universal utility

'use strict';

var yeoman = require('yeoman-generator');

var test = yeoman.Base.extend({
  paths: function () {
    this.sourceRoot(this.sourceRoot() + '/../../../templates');
  },

  writing: function () {
    this.fs.copyTpl(
      this.templatePath('twig/index.twig'),
      this.destinationPath('templates/index.twig'),
      { title: 'Templating with Yeoman!' }
    );
  }
});

module.exports = test;

This way we could for example use the same Twig templates when generating front-end and WP projects with front-end.

There is a problem with the assets building.
Chisel reports such an error from time to time

[12:46:20] Error: ENOENT: no such file or directory, open
I need to make build for the second time or sometimes more.

Current configuration (docs) requires braces to be written like that:

if (foo) {
  bar();
} else {
  baz();
}

While your coding standards require them to be written like that:

if (foo) {
  bar();
}
else {
  baz();
}

One or the other should be updated. Change in generator would be breaking for existing projects.

Generating a functionality plugin to store site specific functionality like custom post types, taxonomies, etc.

Is this how it's supposed to work when there is no data file?

[14:27:52] Starting 'scripts-build'...
[14:27:52] Finished 'assets-watch' after 263 ms
{ Error: ENOENT: no such file or directory, open 'C:\xampp\htdocs\www\dev\fives-concept\src\data\projects.twig.json'
  errno: -4058,
  code: 'ENOENT',
  syscall: 'open',
  path: 'C:\\xampp\\htdocs\\www\\dev\\fives-concept\\src\\data\\projects.twig.json' }
[14:27:52] Finished 'templates-watch' after 409 ms
[14:27:52] Finished 'styles-watch' after 846 ms

Currently git ignores only

node_modules
coverage

greenkeeper is a bot which crawls GH and update project's deps.

Although I'm not sure how we feel about getting all the access needed for it to work.

A simple page presenting Chisel, based on the index page design

Currently mobile styles are always used during printing. Is there any reason for use of "only screen"?

The assets task should only delete assets/ dir instead of dist.

The generator should have the list of most frequently used wp plugins and ask to add them to composer.json file while generating the project.

Examples: ACF, Gravity Forms

• https://github.com/bezoerb/gulp-htmlhint
• https://github.com/callumacrae/gulp-w3cjs
• xfiveco/generator-xh#102

Replacing *.php with **/*.{php,twig} here and limiting that line to WP projects should be enough.

Replace the current feature option for "WordPress support" with a question about project type. They should be like:

• Front-end only
• WordPress with Front-end
• WordPress only <- this one can be added later

This setup would allow us to distinguish among more project types and scaffold the projects accordingly. For example on the WP only project type we don't have to display question about additional front-end features or generate any front-end stuff.

'base' property should be set for twigUpToDate plugin as it allows to use paths relatively to the base templates path and not to current twig files.

Original php library does not allow to use paths relative to current file (usage of .. in paths).

• objects library (#84)
• sample components
• component generator (should be a separate issue)
• etc.

Currently it's sorted alphabetically for some unknown reason.
I believe the declaration-block-properties-order property should be removed from config as it's more of an obstacle than help for maintaining stylesheets.

I mean specifically * text eol=lf.
This causes troubles with PNG images and popular fonts formats like woff, woff2, otf, ttf on UNIX machines.

I have never had troubles working on the repository without .gitattributes specified, regardless the OS of the collaborators.