- Config classes.
UserConfigandTemplateConfig(withdefaultConfigproviding, um, defaults) appear to be the only classes dedicated to configuration (according to their names).
eleventyConfig.- Many class constructors and methods accept an
eleventyConfigargument. - In
Eleventy.initializeConfig(), this is aTemplateConfiginstance. - A
TemplateConfiginstance holds a reference to aUserConfiginstance. If I understand correctly, this is so that a user’s configuration can be tweaked on a template-by-template basis. Is this correct?
- Many class constructors and methods accept an
- “Config” vs. “options”.
- When a class handles both “config” and “options”, what distinguishes whether a setting falls into one category or
| class Boid { | |
| // ... | |
| /** | |
| * @param {Boid} other | |
| * @returns {Boolean} | |
| */ | |
| canSee (other) { | |
| // Adapted from |
-
Modern ES code. ES/JS moves fast these days. I want Metalsmith 3 to be best-in-class, and stay best-in-class for several years.
-
Performance (with Scalability). If Metalsmith 3 can boast performance that is so good, big companies with big websites start using it, that would be pretty fantastic. :)
-
Convenience.
NOTE: This is a question I found on StackOverflow which I’ve archived here, because the answer is so effing phenomenal.
If you are not into long explanations, see [Paolo Bergantino’s answer][2].
This is all based on the [alpha release][1].
From the built-in help system:
For many settings, TextMate will look for a .tm_properties file in the current folder, and in any parent folders (up to the user’s home folder).
These are simple «setting» = «value» listings, where «value» is a format string in which other variables can be referenced.
| # -*- coding: utf-8 -*- | |
| # Modified from original source, available here: | |
| # http://code.activestate.com/recipes/577624-orderedset/ | |
| try: | |
| import collections.abc as collections # Python 3 | |
| except ImportError: | |
| import collections # Python 2 |
| # Small utility which uses the homepage and nokogori to get a description from the formula's homepage. | |
| # | |
| # As written in the homebrew wiki: | |
| # > Homebrew doesn’t have a description field because the homepage is always up to date, | |
| # > and Homebrew is not. Thus it’s less maintenance for us. To satisfy the description | |
| # > we’re going to invent a new packaging microformat and persuade everyone to publish | |
| # > it on their homepage. | |
| # | |
| # Too bad no packaging microformat has yet been invented, but brew-more just first looks for a | |
| # `<meta name="description">` tag, then for an `a#project_summary_link` tag (which is used in |
| <?xml version="1.0" encoding="UTF-8"?> | |
| <!-- | |
| @source | |
| http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html | |
| @author | |
| Zearin <[email protected]> | |
| @license | |
| I haven’t chosen a license yet. In the meantime, feel free to reuse this |
| # Small utility which uses the homepage and nokogori to get a description from the formula's homepage. | |
| # | |
| # As written in the homebrew wiki: | |
| # > Homebrew doesn’t have a description field because the homepage is always up to date, | |
| # > and Homebrew is not. Thus it’s less maintenance for us. To satisfy the description | |
| # > we’re going to invent a new packaging microformat and persuade everyone to publish | |
| # > it on their homepage. | |
| # | |
| # Too bad no packaging microformat has yet been invented, but brew-more just first looks for a | |
| # `<meta name="description">` tag, then for an `a#project_summary_link` tag (which is used in |