micromata / baumeister Goto Github PK

• When a change in the index.html is , you get this error "Fatal error: Unexpected token P" .
  • Nor styles are displayed

… and a module loader instead of using the revealing module pattern relying on the global scope (even with using a namespace to prevent polluting the global scope).

Going to take a closer look at:

• browserify for using CommonJS modules
• SystemJS or ES6 Module Loader polyfill for using ES6 modules

Any thoughts on that @krnlde?

We should consider which tools make sense to improve performance beside automatically generate CSS Sprites (#61)

Does it make sense to use a tool to inline above-the-fold CSS by default?
See above-the-fold CSS Critical-path (Above-the-fold) CSS Tools

Should we add a tool to benchmark and analyse performance?
See http://perf-tooling.today/tools?q=metrics

Any suggestions welcome

//cc @krnlde @mfroehner @uschmidt @revrng @jMengel

I need that. Seriously 😄

Just pass the fix option to the grunt task like described here:
https://github.com/sindresorhus/grunt-eslint#options

The copyright to Micromata is hardcoded in the Gruntfile.js although the pkg.name variable is used to print out the package name.

Here is an example:

banner: '/*! <%= pkg.title %> - v<%= pkg.version %>\n' +
         ' * [email protected]\n' +
         ' * Copyright ©<%= grunt.template.today("yyyy") %> Micromata GmbH\n' +
         ' * <%= grunt.template.today("yyyy-mm-dd") %>\n' +
         ' */',

It would be better to use the pkg.author.email variable or anything comparable to this.

It might happen that you encounter linting errors (htmllint, bootlint, jshint) etc. while running one of the release tasks. Which will lead to creating a Git tag without »finishing« the release.

You could consider calling that an edge case, because it will only happen, if you don’t use the watch task during development. But I guess it’s worth checking how to get rid of these potential problems.

Please note:
It's not fixed by just reordering the tasks within the release-tasks like in the following example

Before:

['bump-only:patch', 'build', 'clean:js', 'changelog', 'bump-commit', 'compress']

After:

['build', 'clean:js', 'bump-only:patch', 'changelog', 'bump-commit', 'compress']

Because that will mess up the releases:

• The »old« version number will be placed within the comment banners of CSS and JS files
• Surprisingly the minified CSS wasn’t updated within the release after that attempt (might be caused by something else. It was late 😄)

Needs further investigation …

Due to the close of tschaub/grunt-newer#86 (comment) we should add a tolerance of about 500ms (just a guess to be safe) for the windows users among us. Should have a huge perf. impact for them.

Some people are doing this to have a »running version« immediately after checkout.

Doesn’t make much sense for the »kickstart« itself. But for the projects based on the »kickstart« it could.

Feedback appreciated

Spritesmith seems to be a good library for this purpose:
https://github.com/Ensighten/grunt-spritesmith

The link used in CONTRIBUTING.md is dead.

The article is still available though under the following link:

https://css-tricks.com/reduced-test-cases/

v1.0.0 has a breaking change in the settings.

See: https://github.com/sapegin/grunt-bower-concat#dest

Especially: Describe how to add CSS and JS to from external libs into the bundled CSS and JS files.

Calling the .postinstall.js script from node install produces an error on Windows 7 systems.
Because Windows doesn't recognize the shebang line in scripts and handles binaries with file endings associated programs. In this case (.js) with the Windows Scripting Host.

replacing the script configuration with:

"scripts": {
    "postinstall": "chmod u+x .postinstall.js && node ./.postinstall.js"
  }

it works again. The important thing here is adding 'node' before .postinstall.js, telling Windows explicit to use node.js to run the script.

Unfortunately i cannot confirm if this change breaks this on Linux or Mac Os systems.

Also read this article: Writing cross-platform Node.js scroll down until "Scripts in package.json", there is the problem also specified with my solution.

Short summary of the problem

We can’t use our variables.less to override Bootstrap variables in Bootstrap 4. Because Sass […]

… to be continued. (Just a reminder for now)

Related to #29

If you have new files in dist since last release the won’t be commited with the release because they are unknown for Git.

Which leads to »refinish« a release by:

1. Deleting the Git tag pointing to your release tag
2. Adding the unknown files to Git
3. git commit --amend
4. Creating a knew tag pointing to the »new« release commit.

That’s it.

Good idea from @mfroehner 👍

We had that once upon a time for our dev files. Which caused some trouble and actually wasn’t needed, because you should simply disable chaching within the devtools (when they are open).

But how about adding this to html files in the distdirectory?
Need to figure that out …

Example:

banner: '/*! <%= pkg.title %> - v<%= pkg.version %>\n' +
    ' * [email protected]\n' +
    ' * Copyright ©<%= grunt.template.today("yyyy") %> Michael Kühnel\n' +
    ' * <%= grunt.template.today("yyyy-mm-dd") %>\n' +
    ' */',

Some People don’t want to have this in their production files.

I think the switch to ESLint makes more sense than adding JSCS.

I guess @krnlde agrees 😊

… but there is one thing I’m still considering. Should we:

• create (and maintain!) an own .eslintrc file
• load a shared config such as eslint-config-standard, eslint-config-airbnb or eslint-config-xo
• choose the most convenient way with XOXO

I would prefer the latter option because of simplicity. I personally prefer the same code styles as @sindresorhus and believe that he will maintain a trustworthy config over here: https://github.com/sindresorhus/eslint-config-xo/blob/master/index.js

@krnlde Are you with me?

This should be easy implemented with the little help from this friend:
https://github.com/wecodemore/grunt-githooks

First of all:
I don’t want to start a flamewar »Gulp« vs »Grunt« vs »npm run scripts« over here 🙈 🙉 🙊

While I would vote for getting rid of a task runner for small projects and use npm run scripts instead I still see the need of a task runner for Bootstrap Kickstart.

Second:
I don’t feel the urgent need to ditch Grunt because things still work, but there might be a few reasons to dump Grunt in favor of Gulp.

Gulp Pros:

• Performance – faster builds and running watch tasks during development
• Better maintained – Grunt seems to be stuck in development. Last Release was in Mai 2014

While I don’t care that much that Gulp Gulp is the most popular »build script solution« it might have a psychological aspects for potential Bootstrap Kickstart users. Because I see issues raising in other open source tools where people ask about switching to Gulp.

Grunt Pros:

• It just works – We dont have to rewrite the whole workflow
• It could be easier to configure for people whose daily business isn’t writing JavaScript. (Configuration over code)

So how this is going to happen?

First I like to implement a small Gulp proof of concept including just a few tasks to measure the performance advantage over Grunt. Because I would like to see if the rewrite is worth the bother.

I would love to get the advantages which come with Gulp 4. But I don’t want to wait until it’s shipped (no release date in sight). I hope it won’t take long. So I think I could start with the alpha version of Gulp4 even if there is a risk that things might change.

Relates to #42

To prevent that UnCSS is killing bootstrap animations 😁

Something like:

uncss: {
  options: {
    ignoreSheets: [/fonts.googleapis/],
    timeout: 2000,
    ignore: [
      /\w\.in/,
      /(#|\.)navbar(\-[a-zA-Z]+)?/,
      /(#|\.)modal(\-[a-zA-Z]+)?/,
      /(#|\.)dropdown(\-[a-zA-Z]+)?/,
      /(#|\.)carousel(\-[a-zA-Z]+)?/,
      /(#|\.)(open)/,
      '.fade',
      '.collapse',
      '.collapsing',
      '.in'
    ]
  },
  dist: {
    src: '<%= config.server %>/*.html',
    dest: 'temp/index.css'
  }
},

timeout: 2000 ensures that all classes that should be added on onDOMContentLoaded are applied.

… within the production ready distdirectory.

How to add CSS and JS to libs.js and libs.css via the bower_concat task.

The Glyphicon fonts from Bootstrap aren't copied into the dist directory when I run grunt build.

See micromata/generator-bootstrap-kickstart/issues/24

Until now we create minified versions of each and every JS file beside built.min.js.
Therefore dist/assets/js ends up being packed with files like:

base.min.js
built.min.js
moduleFoo.min.js
moduleBar.min.js
moduleFooBar.min.js

I don’t see any need for these files (besides built.min.js of course ☺️ )

@krnlde Do you agree with getting rid of them?

Comments like the following doesn’t need to be in the production html files:

<!--
  Replace "no-js" class with "js" in case JavaScript is available.
  You can delete this when you feel the need to make use of modernizr.
-->

@krnlde @mfroehner
I think this is a no-brainer. Thanks for the suggestion 😊

But what to you think about going one step further and use HTMLMinifier to get rid of comments as well as whitespaces and line breaks?

Pros:

• Save a few kilobytes

Cons:

• Inspecting the processed html files within an editor is useless
  • In the browser view in the Dev Tools aren’t affected.
• Might cause problems in oldIEs because I remember browser bugs which are caused by whitespace
  • But as long as I know several bugs are caused by whitespace and can be »fixed« by removing whitespace.

What’s your opinion on that?

Should we intergrate the following into the release tasks?

• Merge to master?
• Push to origin?

Now

grunt.registerTask('releasePatch',
  ['bump-only:patch', 'build', 'changelog', 'bump-commit', 'compress']
);

Then

grunt.registerTask('releasePatch',
  ['bump-only:patch', 'build', 'changelog', 'bump-commit', 'compress', 'git:merge', 'git:push']
);

Could be accomplished with https://github.com/rubenv/grunt-git

Or is this taken to far?
I’m not sure, if I like to merge and push something I haven’t reviewed.

Feedback appreciated

It would be awesome to extend the page /demoElements.html with more elements which show the theme in action.

Right now it’s just a stupid copy of http://getbootstrap.com/examples/theme/

It would be nice if there were forms and stuff and that page too.

Pull Request appreciated

I experience huge loads each time I'm downloading, installing, starting and running the kickstarter project. Most of the tasks that run for development aren't per se necessary at the beginning of a project. Sure we need reports, sure we need imagemin and all that sorts of stuff. But, as the name quotes, a kick-ass start would be the biggest gainer :)

What do you think @mischah ?

Oops 🙈

Reason:

• The build tasks first fires the imagemin task and the copy task afterwards.
  • https://github.com/micromata/bootstrap-kickstart/blob/master/Gruntfile.js#L631-L634
• Images are copied from assets to /dist Within the copy task.
  • So the optimized images are replaced with the original files

Could be fixed with deleting the following line:
https://github.com/micromata/bootstrap-kickstart/blob/master/Gruntfile.js#L303

Thanks @uschmidt for reporting 😘

An ES6+ aware minifier based on the Babel toolchain.

Still heavy in development:
https://github.com/babel/babel-minify

But could be an attractive alternative.

• Delete non minified CSS from Production build
• Merge JavaScript
• Define Bootstrap Modules for Production build
• Add version to »dist« directory?

Should we split that huge monster in separate files handling one task each.

See the following for inspiration:

• https://github.com/use-init/init
• https://github.com/firstandthird/load-grunt-config#example
• http://www.html5rocks.com/en/tutorials/tooling/supercharging-your-gruntfile/
• https://creynders.wordpress.com/2014/02/10/best-way-to-handle-large-grunt-files/
• http://firstandthird.github.io/load-grunt-config/

Update
I’m not sure wether that splitting up the gruntfile really increases maintainibility. Is it easier to browse through multiple files than scroll through one? See Discussion over here: yeoman/generator-webapp#245

Feedback appreciated

There are new variables like the following which are pretty useful 😗

// Allows for customizing button radius independently from global border radius
@btn-border-radius-base:         @border-radius-base;
@btn-border-radius-large:        @border-radius-large;
@btn-border-radius-small:        @border-radius-small;

In fact, I get a whole bunch of errors when I run grunt tasks and the process aborts.

 ➜  grunt tasks
Loading "autoprefixer.js" tasks...ERROR
>> Error: Cannot find module 'browserslist'
Loading "bootlint.js" tasks...ERROR
>> Error: Cannot find module 'cheerio'
Loading "plato.js" tasks...ERROR
>> Error: Cannot find module 'plato'

Running "availabletasks:tasks" (availabletasks) task
Warning: Cannot set property 'info' of undefined Use --force to continue.

Aborted due to warnings.


Execution Time (2015-03-12 09:01:52 UTC)
loading tasks         61ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 42%
availabletasks:tasks  83ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 57%
Total 145ms

Any ideas?

I installed Bootstrap Kickstart with yo bootstrap-kickstart

The following preparations need to be made before firing a release task for the first time to prevent errors:

• Add a changelog.md to version control
  • Might be obsolete when #29 is fixed
• Add an initial git tag according to the version number within package.json

I guess that could be automated 😘

Rename grunt server to grunt serve. Former seems to be something like a »de facto standard«.

We could alias the old name to the new to avoid confusion 😉

The developbranch seems to be the default branch here at github.
I can’t change it, because I don’t have the privileges to edit the repository settings 😒

I guess this has to be done by @unterstein, @tuxBurner or @kreinhard

Using browserify the file size of the bundle can be dramatically reduced by declaring frontend-dependencies like »bootstrap« or »jquery« as external. I think the already modified variant is used in this case. Maybe we should generally declare all dependencies as externally!? Maybe by parsing the dependencies property of the package.json? The other benefit is that the bundling will be faster, because external dependencies aka »vendors« are only bundled once.

Add unit test boilerplate with the following stack:

• mocha (grunt-mocha-phantomjs vs. grunt-karma / karma-mocha)
• chai (using bdd 'expect' style)
• blanket.js for coverage

I get this error and i dont know whats wrong?
I dont change anything.

Running "cssmin:bower" (cssmin) task
Warning: Path must be a string. Received undefined Use --force to continue.

The base.js should be integrated like before. It includes fixes for IE10 bugs.

Example:
You have a project with 10 pages and every page shares elements like footer, header etc.
So If you want to change something in the footer you have to adapt the change in all of the 10 pages.

To avoid this you could make use of includes. This feature is provided by grunt-processhtml. We already use this task in the default bootstrap kickstart but we don’t use the include feature by default.

I think that would be a useful addition although it will increase complexity of the gruntfile because we need an additional directory (and corresponding tasks) to store the builded html to make the server task work.

Another negative connotation: The line numbers of the markup linters (htmllint and bootlint) won’t fit any longer, because we need to lint the combined files (with rendered includes) 😞

consoleLog.txt

Hi,
consoleLog File is attached.
It seems to be a problem with:

http://eslint.org/docs/rules/linebreak-style

under Windows.

...
66:12 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
67:1 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
68:4 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
69:50 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
70:10 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
71:4 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
72:16 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
73:15 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
74:1 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
75:55 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
76:4 error Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style

? 989 problems (989 errors, 0 warnings)

Warning: Task "eslint:check" failed. Use --force to continue.

Aborted due to warnings.
...

Add HTML standard templates from http://getbootstrap.com/getting-started/#examples

This one at least: http://getbootstrap.com/examples/theme/

// Variables
// Mixins
// Styles

So:

bump: {
  options: {
    files: ['package.json', 'bower.json'],
    updateConfigs: ['pkg'],
    commitMessage: 'Release v%VERSION%',
    commitFiles: ['package.json', 'bower.json', 'CHANGELOG.md'],
    tagName: '%VERSION%',
    tagMessage: 'Release v%VERSION%',
    push: false,
  }
}

should be changed into:

bump: {
  options: {
    files: ['package.json', 'bower.json'],
    updateConfigs: ['pkg'],
    commitMessage: 'Release v%VERSION%',
    commitFiles: ['-a'],
    tagName: '%VERSION%',
    tagMessage: 'Release v%VERSION%',
    push: false,
  }
}

In addition it would be useful if new (and untracked) files in the dist directory are added to version control first.

😦