Initial Sass file structure #33

MichaelArestad · 2015-01-10T21:21:20Z

To address #29.

Added basic file structure with a few example modules
Added Sass and Autoprefixer tasks to Gruntfile.js

arschmitz · 2015-01-10T21:25:27Z

package.json

+    "grunt": "0.4.2",
+    "grunt-autoprefixer": "^2.1.0",
+    "grunt-contrib-jshint": "0.10.0",
+    "grunt-contrib-sass": "^0.8.1",


We previously decided, to avoid an annoying ruby dependency when its likely most people have no other need for ruby, to use libsass. So this would be just grunt-sass for that.

Oops. Fixing.

Added grunt-sass but forgot to remove grunt-contrib-sass

arschmitz · 2015-01-10T22:08:46Z

style.css

+  display: table; }
+.clearfix:after {
+  clear: both; }
+/*# sourceMappingURL=style.css.map */


Hmm i'm not sure about how to get it to add the blank link ill have to look into it. Even github view complains about the lack of blank line so i'm sure there must be a way to get it to add it.

We could just not include it as it's a compiled file.

jzaefferer · 2015-01-22T12:02:09Z

We could just not include it as it's a compiled file.

I can't find discussion about this, but while dealing with sass files on an unrelated problem, I wanted to provide some input on that.

The project I'm working on uses sass files and checks in compiled CSS files in parallel. These are minified, so each time a scss file changes, there's a one-line diff on the compiled CSS file. This is fine for serial development on master, since anyone can pull and look at pages without first having to build something. This is painful when rebasing anything, since every commit that changes any scss file will produce a conflict on the CSS file.

Maybe there's a strategy to avoid those conflicts that I'm not aware of? Or is it better to force everyone to compile scss themselves?

jzaefferer · 2015-01-22T12:03:27Z

Gruntfile.js

+				]
+			},
+			src: [
+			"*.css"


Missing indent. Though for single items, you shouldn't need an array anyway, just pass the string directly.

Good catch. Will fix.

MichaelArestad · 2015-01-22T16:41:22Z

This is painful when rebasing anything, since every commit that changes any scss file will produce a conflict on the CSS file.

That's partially why I might prefer to just not include the compiled file. As we're eventually going to have a build system, there's not a huge need to have the compiled file at all.

jzaefferer · 2015-01-22T16:45:20Z

I suppose there is no way around for contributors to compile scss to css, right? So might as well go with that.

Btw. I remember something about only using scss features that are in future CSS specs (or something like that). Does that apply to the few lines that are in this PR?

arschmitz · 2015-01-22T16:45:23Z

@jzaefferer the discussion was brief and in #css-chassis i would say this is still open for discussion

Issues like this are part of why i would prefer to not see built files in the repo.

@sfrisk any thoughts here?

arschmitz · 2015-01-22T16:50:09Z

@jzaefferer yeah actually having built files could add confusion as you might end up with beginner contributors submitting patches on the css files rather then the scss

@jzaefferer as far as future features that is what was discussed. Im not entirely sure on whats in the specs so far. If we are going to have a rule like this we should probably add this to the css style guide to make it clear whats ok not ok to use. @sfrisk thoughts? we will want this settled before we commit any scss i would think?

sfrisk · 2015-01-27T15:19:29Z

I'm leaning towards removing the .css build files and sticking to .scss. I definitely could see the issue with beginners submitting fixes to the css rather than the scss.

Maybe edit the readme as part of this PR (or a separate one) with a "Getting Started" section that explains how to get everything up and running?

arschmitz · 2015-01-27T15:21:23Z

+1 for adding getting started to readme

jzaefferer · 2015-01-27T15:24:23Z

That information should go into CONTRIBUTING.md, though there should be a link to it in the readme.

arschmitz · 2015-01-27T15:27:39Z

@jzaefferer that sort of information is in the readme in all other repos though getting started is probably not the right section name as much as "building chassis"

https://github.com/jquery/jquery-ui#building-jquery-ui
https://github.com/jquery/jquery-mobile#buildcustomization
https://github.com/jquery/jquery#how-to-build-your-own-jquery

jzaefferer · 2015-01-27T15:30:58Z

So were mostly written before contributing guidelines were a feature. They should be moved.

arschmitz · 2015-01-27T15:35:08Z

This does not seem to keep with the spirit, of contributing guidelines, outlines in the blog post you link to. These should be a set of guidelines for contributors to follow when doing a patch. Basically contribute.jquery.org. These are setup instructions, exactly what is whats meant to be in a readme. http://en.wikipedia.org/wiki/README

sfrisk · 2015-01-27T16:05:09Z

How about for now we just have a "Getting Started / Building Chassis" on the Readme for now, so all the necessary information someone might want to know after arriving to the repo is there on the first page. Might help with attracting contributors if they can find out the state of things and how to get started right there on the home page.

On that note, @arschmitz, for your #34 PR, maybe add to the readme the how-to for getting perf testing up and running?

MichaelArestad · 2015-01-27T16:13:42Z

I'll remove the build files and add info to the README.

Quick note: will miss the meeting today.

MichaelArestad · 2015-02-01T21:12:13Z

Added a Getting Started section to the README and removed the built Sass file

arschmitz · 2015-02-01T21:15:44Z

Gruntfile.js

+				map: true,
+
+				// Target-specific options go here.
+				// browser-specific info: https://github.com/ai/autoprefixer#browsers


There comments seem more like documentation for autoprefixer then comments about what we are actually doing here.

I think I'll just remove the comments here.

arschmitz · 2015-02-03T14:31:32Z

@sfrisk agreed. I was looking around at how other projects do this. I don't think we need to explain git. Maybe just add a link to https://help.github.com/articles/set-up-git/ for setup of third party things like git and NPM there are great resources we don't have to maintain. Looking at other projects that use preprocessors they add pretty much no documentation even on building. I think since barrier to contribution, is a big deal to us, we want some documentation here though.

Personally here i would stick to the specific dependencies they need to install ( not how just list them with links ), and then the commands to run to actually build a working version of chassis with brief explanation.

MichaelArestad · 2015-02-03T17:20:55Z

Removed git references and simplified the Readme a bit.

markelog · 2015-02-03T18:15:53Z

README.md

+
+### Building
+
+Once you've cloned Chassis to your machine, run `npm install` and `grunt build` from the root Chassis directory.


grunt build - suggest you to have an npm alias for this, like in core - https://github.com/jquery/jquery/blob/master/package.json#L54 that way you would never have grunt version conflicts.

battaglr · 2015-02-15T13:37:08Z

@MichaelArestad:

That's partially why I might prefer to just not include the compiled file. As we're eventually going to have a build system, there's not a huge need to have the compiled file at all.

👍

I have learned the hard way that including the compiled file will cause some headaches sooner than later.

arschmitz · 2015-03-03T18:03:39Z

Closing replaced by #42

Also adds build instructions to readme and build/watch tasks for builds Closes gh-42 Ref gh-33

Build: add sass

ae180fc

arschmitz reviewed Jan 10, 2015
View reviewed changes

MichaelArestad added 3 commits January 10, 2015 14:48

Build: Switched to libsass task

91ca08e

Build: removed comment

2d0775c

Build: update autoprefixer browser versions

ba97756

arschmitz reviewed Jan 10, 2015
View reviewed changes

MichaelArestad added 3 commits January 10, 2015 15:08

Build: removed lingering ruby sass task

09cfa7d

Build: style > outputStyle

ad5bd41

Build: fixed missing

4da6aa8

jzaefferer reviewed Jan 22, 2015
View reviewed changes

Build: Minor fixes

d994d9c

Build: removed style.css

6e95114

MichaelArestad added 2 commits February 1, 2015 13:55

Build: Merge remote-tracking branch 'upstream/master' into add/29

e91797e

Build: updated README with build instructions

dd6d06b

Build: removed style.css recursively

77886e2

arschmitz reviewed Feb 1, 2015
View reviewed changes

Build: removed comments

962e6df

MichaelArestad added 2 commits February 3, 2015 10:19

Build: removed extra bits from README

62988dd

Build: fixed typo

98d2e72

markelog reviewed Feb 3, 2015
View reviewed changes

arschmitz mentioned this pull request Mar 3, 2015

Sass build #42

Closed

arschmitz closed this Mar 3, 2015

arschmitz pushed a commit that referenced this pull request Mar 5, 2015

Build: Add sass and autoprefixer

0ae0e99

Also adds build instructions to readme and build/watch tasks for builds Closes gh-42 Ref gh-33

MichaelArestad deleted the add/29 branch March 15, 2015 20:54


		### Building

		Once you've cloned Chassis to your machine, run `npm install` and `grunt build` from the root Chassis directory.

Initial Sass file structure #33

Initial Sass file structure #33

Uh oh!

Conversation

MichaelArestad commented Jan 10, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jzaefferer commented Jan 22, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MichaelArestad commented Jan 22, 2015

Uh oh!

jzaefferer commented Jan 22, 2015

Uh oh!

arschmitz commented Jan 22, 2015

Uh oh!

arschmitz commented Jan 22, 2015

Uh oh!

sfrisk commented Jan 27, 2015

Uh oh!

arschmitz commented Jan 27, 2015

Uh oh!

jzaefferer commented Jan 27, 2015

Uh oh!

arschmitz commented Jan 27, 2015

Uh oh!

jzaefferer commented Jan 27, 2015

Uh oh!

arschmitz commented Jan 27, 2015

Uh oh!

sfrisk commented Jan 27, 2015

Uh oh!

MichaelArestad commented Jan 27, 2015

Uh oh!

MichaelArestad commented Feb 1, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arschmitz commented Feb 3, 2015

Uh oh!

MichaelArestad commented Feb 3, 2015

Uh oh!

Choose a reason for hiding this comment

Uh oh!

battaglr commented Feb 15, 2015

Uh oh!

arschmitz commented Mar 3, 2015

Uh oh!

Uh oh!