giga-lite-hub 0.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (87) hide show
  1. checksums.yaml +7 -0
  2. data/giga-lite-hub.gemspec +12 -0
  3. data/sprockets-4.2.2/CHANGELOG.md +118 -0
  4. data/sprockets-4.2.2/MIT-LICENSE +21 -0
  5. data/sprockets-4.2.2/README.md +716 -0
  6. data/sprockets-4.2.2/bin/sprockets +93 -0
  7. data/sprockets-4.2.2/lib/rake/sprocketstask.rb +157 -0
  8. data/sprockets-4.2.2/lib/sprockets/add_source_map_comment_to_asset_processor.rb +60 -0
  9. data/sprockets-4.2.2/lib/sprockets/asset.rb +212 -0
  10. data/sprockets-4.2.2/lib/sprockets/autoload/babel.rb +8 -0
  11. data/sprockets-4.2.2/lib/sprockets/autoload/closure.rb +8 -0
  12. data/sprockets-4.2.2/lib/sprockets/autoload/coffee_script.rb +8 -0
  13. data/sprockets-4.2.2/lib/sprockets/autoload/eco.rb +8 -0
  14. data/sprockets-4.2.2/lib/sprockets/autoload/ejs.rb +8 -0
  15. data/sprockets-4.2.2/lib/sprockets/autoload/jsminc.rb +8 -0
  16. data/sprockets-4.2.2/lib/sprockets/autoload/sass.rb +8 -0
  17. data/sprockets-4.2.2/lib/sprockets/autoload/sassc.rb +8 -0
  18. data/sprockets-4.2.2/lib/sprockets/autoload/uglifier.rb +8 -0
  19. data/sprockets-4.2.2/lib/sprockets/autoload/yui.rb +8 -0
  20. data/sprockets-4.2.2/lib/sprockets/autoload/zopfli.rb +7 -0
  21. data/sprockets-4.2.2/lib/sprockets/autoload.rb +16 -0
  22. data/sprockets-4.2.2/lib/sprockets/babel_processor.rb +66 -0
  23. data/sprockets-4.2.2/lib/sprockets/base.rb +147 -0
  24. data/sprockets-4.2.2/lib/sprockets/bower.rb +61 -0
  25. data/sprockets-4.2.2/lib/sprockets/bundle.rb +105 -0
  26. data/sprockets-4.2.2/lib/sprockets/cache/file_store.rb +208 -0
  27. data/sprockets-4.2.2/lib/sprockets/cache/memory_store.rb +84 -0
  28. data/sprockets-4.2.2/lib/sprockets/cache/null_store.rb +54 -0
  29. data/sprockets-4.2.2/lib/sprockets/cache.rb +271 -0
  30. data/sprockets-4.2.2/lib/sprockets/cached_environment.rb +64 -0
  31. data/sprockets-4.2.2/lib/sprockets/closure_compressor.rb +48 -0
  32. data/sprockets-4.2.2/lib/sprockets/coffee_script_processor.rb +39 -0
  33. data/sprockets-4.2.2/lib/sprockets/compressing.rb +134 -0
  34. data/sprockets-4.2.2/lib/sprockets/configuration.rb +79 -0
  35. data/sprockets-4.2.2/lib/sprockets/context.rb +305 -0
  36. data/sprockets-4.2.2/lib/sprockets/dependencies.rb +74 -0
  37. data/sprockets-4.2.2/lib/sprockets/digest_utils.rb +197 -0
  38. data/sprockets-4.2.2/lib/sprockets/directive_processor.rb +432 -0
  39. data/sprockets-4.2.2/lib/sprockets/eco_processor.rb +33 -0
  40. data/sprockets-4.2.2/lib/sprockets/ejs_processor.rb +32 -0
  41. data/sprockets-4.2.2/lib/sprockets/encoding_utils.rb +261 -0
  42. data/sprockets-4.2.2/lib/sprockets/environment.rb +46 -0
  43. data/sprockets-4.2.2/lib/sprockets/erb_processor.rb +43 -0
  44. data/sprockets-4.2.2/lib/sprockets/errors.rb +12 -0
  45. data/sprockets-4.2.2/lib/sprockets/exporters/base.rb +71 -0
  46. data/sprockets-4.2.2/lib/sprockets/exporters/file_exporter.rb +24 -0
  47. data/sprockets-4.2.2/lib/sprockets/exporters/zlib_exporter.rb +33 -0
  48. data/sprockets-4.2.2/lib/sprockets/exporters/zopfli_exporter.rb +14 -0
  49. data/sprockets-4.2.2/lib/sprockets/exporting.rb +73 -0
  50. data/sprockets-4.2.2/lib/sprockets/file_reader.rb +16 -0
  51. data/sprockets-4.2.2/lib/sprockets/http_utils.rb +135 -0
  52. data/sprockets-4.2.2/lib/sprockets/jsminc_compressor.rb +32 -0
  53. data/sprockets-4.2.2/lib/sprockets/jst_processor.rb +50 -0
  54. data/sprockets-4.2.2/lib/sprockets/loader.rb +347 -0
  55. data/sprockets-4.2.2/lib/sprockets/manifest.rb +339 -0
  56. data/sprockets-4.2.2/lib/sprockets/manifest_utils.rb +48 -0
  57. data/sprockets-4.2.2/lib/sprockets/mime.rb +96 -0
  58. data/sprockets-4.2.2/lib/sprockets/npm.rb +52 -0
  59. data/sprockets-4.2.2/lib/sprockets/path_dependency_utils.rb +77 -0
  60. data/sprockets-4.2.2/lib/sprockets/path_digest_utils.rb +48 -0
  61. data/sprockets-4.2.2/lib/sprockets/path_utils.rb +367 -0
  62. data/sprockets-4.2.2/lib/sprockets/paths.rb +82 -0
  63. data/sprockets-4.2.2/lib/sprockets/preprocessors/default_source_map.rb +49 -0
  64. data/sprockets-4.2.2/lib/sprockets/processing.rb +228 -0
  65. data/sprockets-4.2.2/lib/sprockets/processor_utils.rb +170 -0
  66. data/sprockets-4.2.2/lib/sprockets/resolve.rb +295 -0
  67. data/sprockets-4.2.2/lib/sprockets/sass_cache_store.rb +30 -0
  68. data/sprockets-4.2.2/lib/sprockets/sass_compressor.rb +63 -0
  69. data/sprockets-4.2.2/lib/sprockets/sass_functions.rb +3 -0
  70. data/sprockets-4.2.2/lib/sprockets/sass_importer.rb +3 -0
  71. data/sprockets-4.2.2/lib/sprockets/sass_processor.rb +313 -0
  72. data/sprockets-4.2.2/lib/sprockets/sassc_compressor.rb +56 -0
  73. data/sprockets-4.2.2/lib/sprockets/sassc_processor.rb +297 -0
  74. data/sprockets-4.2.2/lib/sprockets/server.rb +315 -0
  75. data/sprockets-4.2.2/lib/sprockets/source_map_processor.rb +66 -0
  76. data/sprockets-4.2.2/lib/sprockets/source_map_utils.rb +483 -0
  77. data/sprockets-4.2.2/lib/sprockets/transformers.rb +173 -0
  78. data/sprockets-4.2.2/lib/sprockets/uglifier_compressor.rb +66 -0
  79. data/sprockets-4.2.2/lib/sprockets/unloaded_asset.rb +139 -0
  80. data/sprockets-4.2.2/lib/sprockets/uri_tar.rb +99 -0
  81. data/sprockets-4.2.2/lib/sprockets/uri_utils.rb +194 -0
  82. data/sprockets-4.2.2/lib/sprockets/utils/gzip.rb +99 -0
  83. data/sprockets-4.2.2/lib/sprockets/utils.rb +210 -0
  84. data/sprockets-4.2.2/lib/sprockets/version.rb +4 -0
  85. data/sprockets-4.2.2/lib/sprockets/yui_compressor.rb +56 -0
  86. data/sprockets-4.2.2/lib/sprockets.rb +232 -0
  87. metadata +126 -0
@@ -0,0 +1,716 @@
1
+ # Sprockets: Rack-based asset packaging
2
+
3
+ Sprockets is a Ruby library for compiling and serving web assets.
4
+ It features declarative dependency management for JavaScript and CSS
5
+ assets, as well as a powerful preprocessor pipeline that allows you to
6
+ write assets in languages like CoffeeScript, Sass and SCSS.
7
+
8
+ ## Installation
9
+
10
+ Install Sprockets from RubyGems:
11
+
12
+ ``` sh
13
+ $ gem install sprockets
14
+ ```
15
+
16
+ Or include it in your project's `Gemfile` with Bundler:
17
+
18
+ ``` ruby
19
+ gem 'sprockets', '~> 4.0'
20
+ ```
21
+
22
+ ## Upgrading to Sprockets 4.x
23
+
24
+ These are the major features in Sprockets 4.x
25
+
26
+ - Source Maps
27
+ - Manifest.js
28
+ - ES6 support
29
+ - Deprecated processor interface in 3.x is removed in 4.x
30
+
31
+ Read more about them by referencing [Upgrading document](UPGRADING.md)
32
+
33
+ ## Guides
34
+
35
+ For most people interested in using Sprockets, you will want to see the README below.
36
+
37
+ If you are a framework developer that is using Sprockets, see [Building an Asset Processing Framework](guides/building_an_asset_processing_framework.md).
38
+
39
+ If you are a library developer who is extending the functionality of Sprockets, see [Extending Sprockets](guides/extending_sprockets.md).
40
+
41
+ If you want to work on Sprockets or better understand how it works read [How Sprockets Works](guides/how_sprockets_works.md)
42
+
43
+ ## Behavior Overview
44
+
45
+ You can interact with Sprockets primarily through directives and file extensions. This section covers how to use each of these things, and the defaults that ship with Sprockets.
46
+
47
+ Since you are likely using Sprockets through another framework (such as the [the Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html)), there will be configuration options you can toggle that will change behavior such as what directories or files get compiled. For that documentation you should see your framework's documentation.
48
+
49
+ #### Accessing Assets
50
+
51
+ Assets in Sprockets are always referenced by their *logical path*.
52
+
53
+ The logical path is the path of the asset source file relative to its
54
+ containing directory in the load path. For example, if your load path
55
+ contains the directory `app/assets/javascripts`:
56
+
57
+ <table>
58
+ <tr>
59
+ <th>Logical path</th>
60
+ <th>Source file on disk</th>
61
+ </tr>
62
+ <tr>
63
+ <td>application.js</td>
64
+ <td>app/assets/javascripts/application.js</td>
65
+ </tr>
66
+ <tr>
67
+ <td>models/project.js</td>
68
+ <td>app/assets/javascripts/models/project.js</td>
69
+ </tr>
70
+ <tr>
71
+ <td>hello.js</td>
72
+ <td>app/assets/javascripts/hello.coffee</td>
73
+ </tr>
74
+ </table>
75
+
76
+ > Note: For assets that are compiled or transpiled, you want to specify the extension that you want, not the extension on disk. For example we specified `hello.js` even if the file on disk is a coffeescript file, since the asset it will generate is javascript.
77
+
78
+ ### Directives
79
+
80
+ Directives are special comments in your asset file and the main way of interacting with processors. What kind of interactions? You can use these directives to tell Sprockets to load other files, or specify dependencies on other assets.
81
+
82
+ For example, let's say you have custom JavaScript that you've written. You put this javascript in a file called `beta.js`. The javascript makes heavy use of jQuery, so you need to load that before your code executes. You could add a `require` directive to the top of `beta.js`:
83
+
84
+ ```js
85
+ //= require jquery
86
+
87
+ $().ready({
88
+ // my custom code here
89
+ })
90
+ ```
91
+
92
+ The directive processor understands comment blocks in three formats:
93
+
94
+ ``` css
95
+ /* Multi-line comment blocks (CSS, SCSS, JavaScript)
96
+ *= require foo
97
+ */
98
+ ```
99
+
100
+ ``` js
101
+ // Single-line comment blocks (SCSS, JavaScript)
102
+ //= require foo
103
+ ```
104
+
105
+ ``` coffee
106
+ # Single-line comment blocks (CoffeeScript)
107
+ #= require foo
108
+ ```
109
+
110
+ > Note: Directives are only processed if they come before any application code. Once you have a line that does not include a comment or whitespace then Sprockets will stop looking for directives. If you use a directive outside of the "header" of the document it will not do anything, and won't raise any errors.
111
+
112
+ Here is a list of the available directives:
113
+
114
+ - [`require`](#require) - Add the contents of a file to current
115
+ - [`require_self`](#require_self) - Change order of where current contents are concatenated to current
116
+ - [`require_directory`](#require_directory) - Add contents of each file in a folder to current
117
+ - [`require_tree`](#require_tree) - Add contents of all files in all directories in a path to current
118
+ - [`link`](#link) - Make target file compile and be publicly available without adding contents to current
119
+ - [`link_directory`](#link_directory) - Make target directory compile and be publicly available without adding contents to current
120
+ - [`link_tree`](#link_tree) - Make target tree compile and be publicly available without adding contents to current
121
+ - [`depend_on`](#depend_on) - Recompile current file if target has changed
122
+ - [`depend_on_directory`](#depend_on_directory) - Recompile current file if any files in target directory has changed
123
+ - [`stub`](#stub) - Ignore target file
124
+
125
+ You can see what each of these does below.
126
+
127
+ ### Specifying Processors through File Extensions
128
+
129
+ Sprockets uses the filename extensions to determine what processors to run on your file and in what order. For example if you have a file:
130
+
131
+ ```
132
+ application.scss
133
+ ```
134
+
135
+ Then Sprockets will by default run the sass processor (which implements scss). The output file will be converted to css.
136
+
137
+ You can specify multiple processors by specifying multiple file extensions. For example you can use Ruby's [ERB template language](#invoking-ruby-with-erb) to embed content in your doc before running the sass processor. To accomplish this you would need to name your file
138
+
139
+ ```
140
+ application.scss.erb
141
+ ```
142
+
143
+ Processors are run from right to left (tail to head), so in the above example the processor associated with `erb` will be run before the processor associated with `scss` extension.
144
+
145
+ For a description of the processors that Sprockets has by default see the "default processors" section below. Other libraries may register additional processors.
146
+
147
+ When "asking" for a compiled file, you always ask for the extension you want. For example if you're using Rails, to get the contents of `application.scss.erb` you would use
148
+
149
+ ```
150
+ asset_path("application.css")
151
+ ```
152
+
153
+ Sprockets understands that `application.scss.erb` will compile down to a `application.css`. Ask for what you need, not what you have.
154
+
155
+ If this isn't working like you expect, make sure you didn't typo an extension, and make sure the file is on a "load path" (see framework docs for adding new load paths).
156
+
157
+ ## File Order Processing
158
+
159
+ By default files are processed in alphabetical order. This behavior can impact your asset compilation when one asset needs to be loaded before another.
160
+
161
+ For example if you have an `application.js` and it loads another directory
162
+
163
+ ```js
164
+ //= require_directory my_javascript
165
+ ```
166
+
167
+ The files in that directory will be loaded in alphabetical order. If the directory looks like this:
168
+
169
+ ```sh
170
+ $ ls -1 my_javascript/
171
+
172
+ alpha.js
173
+ beta.js
174
+ jquery.js
175
+ ```
176
+
177
+ Then `alpha.js` will be loaded before either of the other two. This can be a problem if `alpha.js` uses jquery. For this reason it is not recommend to use `require_directory` with files that are ordering dependent. You can either require individual files manually:
178
+
179
+ ```js
180
+ //= require jquery
181
+ //= require alpha
182
+ //= require beta
183
+ ```
184
+
185
+ Or you can use index files to proxy your folders.
186
+
187
+ ### Index files are proxies for folders
188
+
189
+ In Sprockets index files such as `index.js` or `index.css` files inside of a folder will generate a file with the folder's name. So if you have a `foo/index.js` file it will compile down to `foo.js`. This is similar to NPM's behavior of using [folders as modules](https://nodejs.org/api/modules.html#modules_folders_as_modules). It is also somewhat similar to the way that a file in `public/my_folder/index.html` can be reached by a request to `/my_folder`. This means that you cannot directly use an index file. For example this would not work:
190
+
191
+ ```erb
192
+ <%= asset_path("foo/index.js") %>
193
+ ```
194
+
195
+ Instead you would need to use:
196
+
197
+ ```erb
198
+ <%= asset_path("foo.js") %>
199
+ ```
200
+
201
+ Why would you want to use this behavior? It is common behavior where you might want to include an entire directory of files in a top level JavaScript. You can do this in Sprockets using `require_tree .`
202
+
203
+ ```js
204
+ //= require_tree .
205
+ ```
206
+
207
+ This has the problem that files are required alphabetically. If your directory has `jquery-ui.js` and `jquery.min.js` then Sprockets will require `jquery-ui.js` before `jquery` is required which won't work (because jquery-ui depends on jquery). Previously the only way to get the correct ordering would be to rename your files, something like `0-jquery-ui.js`. Instead of doing that you can use an index file.
208
+
209
+ For example, if you have an `application.js` and want all the files in the `foo/` folder you could do this:
210
+
211
+ ```js
212
+ //= require foo.js
213
+ ```
214
+
215
+ Then create a file `foo/index.js` that requires all the files in that folder in any order you want using relative references:
216
+
217
+ ```js
218
+ //= require ./foo.min.js
219
+ //= require ./foo-ui.js
220
+ ```
221
+
222
+ Now in your `application.js` will correctly load the `foo.min.js` before `foo-ui.js`. If you used `require_tree` it would not work correctly.
223
+
224
+ ## Cache
225
+
226
+ Compiling assets is slow. It requires a lot of disk use to pull assets off of hard drives, a lot of RAM to manipulate those files in memory, and a lot of CPU for compilation operations. Because of this Sprockets has a cache to speed up asset compilation times. That's the good news. The bad news, is that sprockets has a cache and if you've found a bug it's likely going to involve the cache.
227
+
228
+ By default Sprockets uses the file system to cache assets. It makes sense that Sprockets does not want to generate assets that already exist on disk in `public/assets`, what might not be as intuitive is that Sprockets needs to cache "partial" assets.
229
+
230
+ For example if you have an `application.js` and it is made up of `a.js`, `b.js`, all the way to `z.js`
231
+
232
+ ```js
233
+ //= require a.js
234
+ //= require b.js
235
+ # ...
236
+ //= require z.js
237
+ ```
238
+
239
+ The first time this file is compiled the `application.js` output will be written to disk, but also intermediary compiled files for `a.js` etc. will be written to the cache directory (usually `tmp/cache/assets`).
240
+
241
+ So, if `b.js` changes it will get recompiled. However instead of having to recompile the other files from `a.js` to `z.js` since they did not change, we can use the prior intermediary files stored in the cached values . If these files were expensive to generate, then this "partial" asset cache strategy can save a lot of time.
242
+
243
+ Directives such as `require`, `link`, `depend_on`, and `depend_on_directory` tell Sprockets what assets need to be re-compiled when a file changes. Files are considered "fresh" based on their mtime on disk and a combination of cache keys.
244
+
245
+ On Rails you can force a "clean" install by clearing the `public/assets` and `tmp/cache/assets` directories.
246
+
247
+
248
+ ## Default Directives
249
+
250
+ Directives take a path or a path to a file. Paths for directive can be relative to the current file, for example:
251
+
252
+ ```js
253
+ //= require ../foo.js
254
+ ```
255
+
256
+ This would load the file up one directory and named `foo.js`. However this isn't required if `foo.js` is on one of Sprocket's load paths. You can simply use
257
+
258
+ ```js
259
+ //= require foo.js
260
+ ```
261
+
262
+ Without any prepended dots and sprockets will search for the asset. If the asset is on a sub-path of the load path, you can specify it without using a relative path as well:
263
+
264
+ ```js
265
+ //= require sub/path/foo.js
266
+ ```
267
+
268
+ You can also use an absolute path, but this is discouraged unless you know the directory structure of every machine you plan on running code on.
269
+
270
+ Below is a section for each of the built in directive types supported by Sprockets.
271
+
272
+ ### require
273
+
274
+ `require` *path* inserts the contents of the asset source file
275
+ specified by *path*. If the file is required multiple times, it will
276
+ appear in the bundle only once.
277
+
278
+ **Example:**
279
+
280
+ If you've got an `a.js`:
281
+
282
+ ```js
283
+ var a = "A";
284
+ ```
285
+
286
+ and a `b.js`;
287
+
288
+ ```js
289
+ var b = "B";
290
+ ```
291
+
292
+ Then you could require both of these in an `application.js`
293
+
294
+ ```js
295
+ //= require a.js
296
+ //= require b.js
297
+ ```
298
+
299
+ Which would generate one concatenated file:
300
+
301
+ ```js
302
+ var a = "A";
303
+ var b = "B";
304
+ ```
305
+
306
+ ### require_self
307
+
308
+ `require_self` tells Sprockets to insert the body of the current
309
+ source file before any subsequent `require` directives.
310
+
311
+ **Example:**
312
+
313
+ If you've got an `a.js`:
314
+
315
+ ```js
316
+ var a = "A";
317
+ ```
318
+
319
+ And an `application.js`
320
+
321
+ ```js
322
+ //= require_self
323
+ //= require 'a.js'
324
+
325
+ var app_name = "Sprockets";
326
+ ```
327
+
328
+ Then this will take the contents of `application.js` (that come after the last require) and put them at the beginning of the file:
329
+
330
+ ```js
331
+ var app_name = "Sprockets";
332
+ var a = "A";
333
+ ```
334
+
335
+ ### require_directory
336
+
337
+ `require_directory` *path* requires all source files of the same
338
+ format in the directory specified by *path*. Files are required in
339
+ alphabetical order.
340
+
341
+ **Example:**
342
+
343
+ If we've got a directory called `alphabet` with an `a.js` and `b.js` files like before, then our `application.js`
344
+
345
+ ```js
346
+ //= require_directory alphabet
347
+ ```
348
+
349
+ Would produce:
350
+
351
+ ```js
352
+ var a = "A";
353
+ var b = "B";
354
+ ```
355
+
356
+ You can also see [Index files are proxies for folders](#index-files-are-proxies-for-folders) for another method of organizing folders that will give you more control.
357
+
358
+ ### require_tree
359
+
360
+ `require_tree` *path* works like `require_directory`, but operates
361
+ recursively to require all files in all subdirectories of the
362
+ directory specified by *path*.
363
+
364
+ ### link
365
+
366
+ `link` *path* declares a dependency on the target *path* and adds it to a list
367
+ of subdependencies to be compiled when the asset is written out to
368
+ disk.
369
+
370
+ Example:
371
+
372
+ If you've got a `manifest.js` file and you want to specify that a `admin.js` source file should be
373
+ generated and made available to the public you can link it by including this in the `manifest.js` file:
374
+
375
+ ```
376
+ //= link admin.js
377
+ ```
378
+
379
+ The argument to `link` is a _logical path_, that is it will be resolved according to the
380
+ configured asset load paths. See [Accessing Assets](#accessing-assets) above. A path relative to
381
+ the current file won't work, it must be a logical path.
382
+
383
+ **Caution**: the "link" directive should always have an explicit extension on the end.
384
+
385
+ `link` can also be used to include manifest files from mounted Rails engines:
386
+
387
+ ```
388
+ //= link my_engine_manifest
389
+ ```
390
+
391
+ This would find a manifest file at `my_engine/app/assets/config/my_engine_manifest.js` and include its directives.
392
+
393
+ ### link_directory
394
+
395
+ `link_directory` *path* links all the files inside the directory specified by the *path*. By "link", we mean they are specified as compilation targets to be written out to disk, and made available to be served to user-agents.
396
+
397
+ Files in subdirectories will not be linked (Compare to [link_tree](#link_tree)).
398
+
399
+ The *path* argument to `link_directory` is _not_ a logical path (it does not use the asset load paths), but is a path relative to the file the `link_directory` directive is found in, and can use `..` to . For instance, you might want:
400
+
401
+ ```js
402
+ //= link_directory ../stylesheets
403
+ ```
404
+
405
+ `link_directory` can take an optional second argument with an extension or content-type, with the
406
+ two arguments separated by a space:
407
+
408
+ ```js
409
+ //= link_directory ../stylesheets text/css
410
+ //= link_directory ../more_stylesheets .css
411
+ ```
412
+
413
+ This will limit the matching files to link to only files recognized as that type. An extension is
414
+ just a shortcut for the type referenced, it does not need to match the source file exactly, but
415
+ instead identifies the content-type the source file must be recognized as.
416
+
417
+ ### link_tree
418
+
419
+ `link_tree` *path* works like [link_directory](#link_directory), but operates
420
+ recursively to link all files in all subdirectories of the
421
+ directory specified by *path*.
422
+
423
+ Example:
424
+
425
+ ```js
426
+ //= link_tree ./path/to/folder
427
+ ```
428
+
429
+ Like `link_directory`, the argument is path relative to the current file, it is *not* a 'logical path' tresolved against load paths.
430
+
431
+
432
+ As with `link_directory`, you can also specify a second argument -- separated by a space -- so any extra files not matching the content-type specified will be ignored:
433
+
434
+ ```js
435
+ //= link_tree ./path/to/folder text/javascript
436
+ //= link_tree ./path/to/other_folder .js
437
+ ```
438
+
439
+
440
+ ### depend_on
441
+
442
+ `depend_on` *path* declares a dependency on the given *path* without
443
+ including it in the bundle. This is useful when you need to expire an
444
+ asset's cache in response to a change in another file.
445
+
446
+ **Example:**
447
+
448
+ If you have a file such as `bar.data` and you're using data from that file in another file, then
449
+ you need to tell sprockets that it needs to re-compile the file if `bar.data` changes:
450
+
451
+ ```js
452
+ //= depend_on "bar.data"
453
+
454
+ var bar = '<%= File.read("bar.data") %>'
455
+ ```
456
+
457
+ To depend on an entire directory containing multiple files, use `depend_on_directory`
458
+
459
+ ### depend_on_asset
460
+
461
+ `depend_on_asset` *path* works like `depend_on`, but operates
462
+ recursively reading the file and following the directives found. This is automatically implied if you use `link`, so consider if it just makes sense using `link` instead of `depend_on_asset`.
463
+
464
+ ### depend_on_directory
465
+
466
+ `depend_on_directory` *path* declares all files in the given *path* without
467
+ including them in the bundle. This is useful when you need to expire an
468
+ asset's cache in response to a change in multiple files in a single directory.
469
+
470
+ All paths are relative to your declaration and must begin with `./`
471
+
472
+ Also, your must include these directories in your [load path](guides/building_an_asset_processing_framework.md#the-load-path).
473
+
474
+ **Example:**
475
+
476
+ If we've got a directory called `data` with files `a.data` and `b.data`
477
+
478
+ ```
479
+ // ./data/a.data
480
+ A
481
+ ```
482
+
483
+ ```
484
+ // ./data/b.data
485
+ B
486
+ ```
487
+
488
+ ```
489
+ // ./file.js.erb
490
+ //= depend_on_directory ./data
491
+ var a = '<% File.read('data/a.data') %>'
492
+ var b = '<% File.read('data/b.data') %>'
493
+ ```
494
+
495
+ Would produce:
496
+
497
+ ```js
498
+ var a = "A";
499
+ var b = "B";
500
+ ```
501
+
502
+ You can also see [Index files are proxies for folders](#index-files-are-proxies-for-folders) for another method of organizing folders that will give you more control.
503
+
504
+ ### stub
505
+
506
+ `stub` *path* excludes that asset and its dependencies from the asset bundle.
507
+ The *path* must be a valid asset and may or may not already be part
508
+ of the bundle. `stub` should only be used at the top level bundle, not
509
+ within any subdependencies.
510
+
511
+ ### Invoking Ruby with ERB
512
+
513
+ Sprockets provides an ERB engine for preprocessing assets using
514
+ embedded Ruby code. Append `.erb` to a CSS or JavaScript asset's
515
+ filename to enable the ERB engine.
516
+
517
+ For example if you have an `app/application/javascripts/app_name.js.erb`
518
+ you could have this in the template
519
+
520
+ ```js
521
+ var app_name = "<%= ENV['APP_NAME'] %>";
522
+ ```
523
+
524
+ Generated files are cached. If you're using an `ENV` var then
525
+ when you change then ENV var the asset will be forced to
526
+ recompile. This behavior is only true for environment variables,
527
+ if you are pulling a value from somewhere else, such as a database,
528
+ you must manually invalidate the cache to see the change.
529
+
530
+ If you're using Rails, there are helpers you can use such as `asset_url`
531
+ that will cause a recompile if the value changes.
532
+
533
+ For example if you have this in your `application.css`
534
+
535
+ ``` css
536
+ .logo {
537
+ background: url(<%= asset_url("logo.png") %>)
538
+ }
539
+ ```
540
+
541
+ When you modify the `logo.png` on disk, it will force `application.css` to be
542
+ recompiled so that the fingerprint will be correct in the generated asset.
543
+
544
+ You can manually make sprockets depend on any other file that is generated
545
+ by sprockets by using the `depend_on` or `depend_on_directory` directive. Rails
546
+ implements the above feature by auto calling `depend_on` on the original asset
547
+ when the `asset_url` is used inside of an asset.
548
+
549
+ ### Styling with Sass and SCSS
550
+
551
+ [Sass](http://sass-lang.com/) is a language that compiles to CSS and
552
+ adds features like nested rules, variables, mixins and selector
553
+ inheritance.
554
+
555
+ If the `sass` gem is available to your application, you can use Sass
556
+ to write CSS assets in Sprockets.
557
+
558
+ Sprockets supports both Sass syntaxes. For the original
559
+ whitespace-sensitive syntax, use the extension `.sass`. For the
560
+ new SCSS syntax, use the extension `.scss`.
561
+
562
+ In Rails if you have `app/application/stylesheets/foo.scss` it can
563
+ be referenced with `<%= asset_path("foo.css") %>`. When referencing
564
+ an asset in Rails, always specify the extension you want. Sprockets will
565
+ convert `foo.scss` to `foo.css`.
566
+
567
+ ### Scripting with CoffeeScript
568
+
569
+ [CoffeeScript](http://jashkenas.github.io/coffeescript/) is a
570
+ language that compiles to the "good parts" of JavaScript, featuring a
571
+ cleaner syntax with array comprehensions, classes, and function
572
+ binding.
573
+
574
+ If the `coffee-script` gem is available to your application, you can
575
+ use CoffeeScript to write JavaScript assets in Sprockets. Note that
576
+ the CoffeeScript compiler is written in JavaScript, and you will need
577
+ an [ExecJS](https://github.com/rails/execjs)-supported runtime
578
+ on your system to invoke it.
579
+
580
+ To write JavaScript assets with CoffeeScript, use the extension
581
+ `.coffee`.
582
+
583
+ In Rails if you have `app/application/javascripts/foo.coffee` it can
584
+ be referenced with `<%= asset_path("foo.js") %>`. When referencing
585
+ an asset in Rails, always specify the extension you want. Sprockets will
586
+ convert `foo.coffee` to `foo.js`.
587
+
588
+
589
+ ## ES6 Support
590
+
591
+ Sprockets 4 ships with a Babel processor. This allows you to transpile ECMAScript6 to JavaScript just like you would transpile CoffeeScript to JavaScript. To use this, modify your Gemfile:
592
+
593
+ ```ruby
594
+ gem 'babel-transpiler'
595
+ ```
596
+
597
+ Any asset with the extension `es6` will be treated as an ES6 file:
598
+
599
+ ```es6
600
+ // app/assets/javascript/application.es6
601
+
602
+ var square = (n) => n * n
603
+
604
+ console.log(square);
605
+ ```
606
+
607
+ Start a Rails server in development mode and visit `localhost:3000/assets/application.js`, and this asset will be transpiled to JavaScript:
608
+
609
+ ```js
610
+ var square = function square(n) {
611
+ return n * n;
612
+ };
613
+
614
+ console.log(square);
615
+ ```
616
+
617
+
618
+ ### JavaScript Templating with EJS and Eco
619
+
620
+ Sprockets supports *JavaScript templates* for client-side rendering of
621
+ strings or markup. JavaScript templates have the special format
622
+ extension `.jst` and are compiled to JavaScript functions.
623
+
624
+ When loaded, a JavaScript template function can be accessed by its
625
+ logical path as a property on the global `JST` object. Invoke a
626
+ template function to render the template as a string. The resulting
627
+ string can then be inserted into the DOM.
628
+
629
+ ```
630
+ <!-- templates/hello.jst.ejs -->
631
+ <div>Hello, <span><%= name %></span>!</div>
632
+
633
+ // application.js
634
+ //= require templates/hello
635
+ $("#hello").html(JST["templates/hello"]({ name: "Sam" }));
636
+ ```
637
+
638
+ Sprockets supports two JavaScript template languages:
639
+ [EJS](https://github.com/sstephenson/ruby-ejs), for embedded
640
+ JavaScript, and [Eco](https://github.com/sstephenson/ruby-eco), for
641
+ embedded CoffeeScript. Both languages use the familiar `<% … %>`
642
+ syntax for embedding logic in templates.
643
+
644
+ If the `ejs` gem is available to your application, you can use EJS
645
+ templates in Sprockets. EJS templates have the extension `.jst.ejs`.
646
+
647
+ If the `eco` gem is available to your application, you can use [Eco
648
+ templates](https://github.com/sstephenson/eco) in Sprockets. Eco
649
+ templates have the extension `.jst.eco`. Note that the `eco` gem
650
+ depends on the CoffeeScript compiler, so the same caveats apply as
651
+ outlined above for the CoffeeScript engine.
652
+
653
+ ### Minifying Assets
654
+
655
+ Several JavaScript and CSS minifiers are available through shorthand.
656
+
657
+ In Rails you will specify them with:
658
+
659
+ ```ruby
660
+ config.assets.js_compressor = :terser
661
+ config.assets.css_compressor = :scss
662
+ ```
663
+
664
+ If you're not using Rails, configure this directly on the "environment".
665
+
666
+ ``` ruby
667
+ environment.js_compressor = :terser
668
+ environment.css_compressor = :scss
669
+ ```
670
+
671
+ If you are using Sprockets directly with a Rack app, don't forget to add
672
+ the `terser` and `sass` gems to your Gemfile when using above options.
673
+
674
+ ### Gzip
675
+
676
+ By default when Sprockets generates a compiled asset file it will also produce a gzipped copy of that file. Sprockets only gzips non-binary files such as CSS, javascript, and SVG files.
677
+
678
+ For example if Sprockets is generating
679
+
680
+ ```
681
+ application-12345.css
682
+ ```
683
+
684
+ Then it will also generate a compressed copy in
685
+
686
+ ```
687
+ application-12345.css.gz
688
+ ```
689
+
690
+ This behavior can be disabled, refer to your framework specific documentation.
691
+
692
+ ### Serving Assets
693
+
694
+ In production you should generate your assets to a directory on disk and serve them either via Nginx or a feature like Rail's `config.public_file_server.enabled = true`.
695
+
696
+ On Rails you can generate assets by running:
697
+
698
+ ```term
699
+ $ RAILS_ENV=production rake assets:precompile
700
+ ```
701
+
702
+ In development Rails will serve assets from `Sprockets::Server`.
703
+
704
+ ## Contributing to Sprockets
705
+
706
+ Sprockets is the work of hundreds of contributors. You're encouraged to submit pull requests, propose
707
+ features and discuss issues.
708
+
709
+ See [CONTRIBUTING](CONTRIBUTING.md).
710
+
711
+ ### Version History
712
+
713
+ Please see the [CHANGELOG](https://github.com/rails/sprockets/tree/master/CHANGELOG.md)
714
+
715
+ ## License
716
+ Sprockets is released under the [MIT License](MIT-LICENSE).