Merge branch 'bug/fix_sass_dependency_#45'

Ryan Glover
2 parents 82b9bfb351 8d88ba9bc5
Showing 3 changed files Show diff stats
.meteor/packages
.meteor/versions
README.md
@@ -12,7 +12,6 @@ check
 audit-argument-checks
 iron:router
 themeteorchef:jquery-validation
-particle4dev:sass@0.3.0
 twbs:bootstrap
 browser-policy
 meteorhacks:npm
@@ -21,3 +20,4 @@ meteorhacks:npm
 npm-container
 themeteorchef:bert
 meteorhacks:ssr
+fourseven:scss
@@ -18,6 +18,7 @@ deps@1.0.7
 ejson@1.0.6
 email@1.0.6
 fastclick@1.0.3
+fourseven:scss@2.1.1
 geojson-utils@1.0.3
 html-tools@1.0.4
 htmljs@1.0.4
@@ -50,7 +51,6 @@ npm-bcrypt@0.7.8_2
 npm-container@1.0.0
 observe-sequence@1.0.6
 ordered-dict@1.0.3
-particle4dev:sass@0.3.0
 random@1.0.3
 reactive-dict@1.1.0
 reactive-var@1.0.5
@@ -17,7 +17,7 @@ For more detail on updates, [read the Changelog](https://github.com/themeteorche
 - jQuery - `meteor add jquery`
 - jQuery Validation - `meteor add themeteorchef:jquery-validation`
 - NPM - `meteor add meteorhacks:npm`
-- Sass - `meteor add particle4dev:sass@0.3.0`
+- Sass - `meteor add fourseven:scss`
 - SSR - `meteor add meteorhacks:ssr`
 - Underscore - `meteor add underscore`
  
@@ -118,7 +118,7 @@ CSS in Base is written using [Sass](http://sass-lang.com).
 ###### Configuration
 Base includes a pattern for managing your API keys, connection strings, and other configuration information using two files: `settings-development.json` and `settings-production.json`. This pattern separates your development and production configuration into two separate files for the sake of security.
  
-Per [Josh Owen's article](http://joshowens.me/environment-settings-and-security-with-meteor-js/), it's considered "bad practice" to check your production keys into your repo (private or otherwise). Base accounts for this by giving you two separate files, but also specifies that your `settings-production.json` file should be ignored by git in `.gitignore`.
+Per [Josh Owens' article](http://joshowens.me/environment-settings-and-security-with-meteor-js/), it's considered "bad practice" to check your production keys into your repo (private or otherwise). Base accounts for this by giving you two separate files, but also specifies that your `settings-production.json` file should be ignored by git in `.gitignore`.
  
 This means that keys that are only used for testing or development purposes can be placed in `settings-development.json`, while keys used in your production application should be placed in `settings-production.json`. Sharing and management of `settings-production.json` should be done on a person-to-person basis and _not_ made globally accessible.
...	...	@@ -12,7 +12,6 @@ check
12	12	audit-argument-checks
13	13	iron:router
14	14	themeteorchef:jquery-validation
15		-particle4dev:sass@0.3.0
16	15	twbs:bootstrap
17	16	browser-policy
18	17	meteorhacks:npm
...	...	@@ -21,3 +20,4 @@ meteorhacks:npm
21	20	npm-container
22	21	themeteorchef:bert
23	22	meteorhacks:ssr
	23	+fourseven:scss
...	...
...	...	@@ -18,6 +18,7 @@ deps@1.0.7
18	18	ejson@1.0.6
19	19	email@1.0.6
20	20	fastclick@1.0.3
	21	+fourseven:scss@2.1.1
21	22	geojson-utils@1.0.3
22	23	html-tools@1.0.4
23	24	htmljs@1.0.4
...	...	@@ -50,7 +51,6 @@ npm-bcrypt@0.7.8_2
50	51	npm-container@1.0.0
51	52	observe-sequence@1.0.6
52	53	ordered-dict@1.0.3
53		-particle4dev:sass@0.3.0
54	54	random@1.0.3
55	55	reactive-dict@1.1.0
56	56	reactive-var@1.0.5
...	...
...	...	@@ -17,7 +17,7 @@ For more detail on updates, [read the Changelog](https://github.com/themeteorche
17	17	- jQuery - `meteor add jquery`
18	18	- jQuery Validation - `meteor add themeteorchef:jquery-validation`
19	19	- NPM - `meteor add meteorhacks:npm`
20		-- Sass - `meteor add particle4dev:sass@0.3.0`
	20	+- Sass - `meteor add fourseven:scss`
21	21	- SSR - `meteor add meteorhacks:ssr`
22	22	- Underscore - `meteor add underscore`
23	23
...	...	@@ -118,7 +118,7 @@ CSS in Base is written using [Sass](http://sass-lang.com).
118	118	###### Configuration
119	119	Base includes a pattern for managing your API keys, connection strings, and other configuration information using two files: `settings-development.json` and `settings-production.json`. This pattern separates your development and production configuration into two separate files for the sake of security.
120	120
121		-Per [Josh Owen's article](http://joshowens.me/environment-settings-and-security-with-meteor-js/), it's considered "bad practice" to check your production keys into your repo (private or otherwise). Base accounts for this by giving you two separate files, but also specifies that your `settings-production.json` file should be ignored by git in `.gitignore`.
	121	+Per [Josh Owens' article](http://joshowens.me/environment-settings-and-security-with-meteor-js/), it's considered "bad practice" to check your production keys into your repo (private or otherwise). Base accounts for this by giving you two separate files, but also specifies that your `settings-production.json` file should be ignored by git in `.gitignore`.
122	122
123	123	This means that keys that are only used for testing or development purposes can be placed in `settings-development.json`, while keys used in your production application should be placed in `settings-production.json`. Sharing and management of `settings-production.json` should be done on a person-to-person basis and _not_ made globally accessible.
124	124
...	...