While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
lib/ is intended for code that can run as-issrc/ is intended for code that needs to be manipulated before it can be used
DISCLAIMER:
The whole content comes "as is".
All commentaries refer to author's impression.
Some inconsistency possible as well.
The few details (mainly useful links) were added while transcribing notes.
From Imperium by Ryszard Kapuściński, first published in Poland in 1993:
Page 277
It is not surprising that the Ukrainian Language Society was among those groups attacked and oppressed. The revolution in the Ukraine, like everywhere else, was waged at least partly over language. Half of the fifty-two million inhabitants of the Ukraine either do not speak Ukrainian, or they speak it poorly. Three hundred and fifty years of Russification have inevitably produced such a result. The ban against printing book in Ukrainian was in force for decades. As early as 1876, Alexander II ordered that instruction in Ukrainian schools take place only in Russian. Several months ago I visited the third-largest city in the Ukraine — Donetsk. The battle to open at least one elementary school teaching Ukrainian was by then already in its second year. Teachers assembled children in the park and there instructed them in Ukrainian. Teaching Ukrainian? Why, that was counterrevolution, an imperialist conspiracy!
Also in Donets
Individual modules of es5-ext package. See ES6 features for usage information.
Today I had a brief debate on twitter about AMD vs CommonJS, https://twitter.com/TechWraith/status/441387541778808832. It's a debate worth having for sure. But I had to bail out of this one. The thing that annoyed me is that the first argument that people bring up to disquality AMD is "the syntax is too complex". I disagree with this. There are lots of reasons to prefer CommonJS over AMD, but the module authoring syntax is not a very good one. There was also a related statement that AMD authoring introduces more "cognitive overhead". This is absolutely true. But I don't consider this to be synonymous with "complexity" by any means.
So I thought I'd explore some comparable examples. Here's a simple one that was offered up by someone else in the thread. This was on twitter so I can forgive erring on the side of brevity.
AMD
define('myThing', ['some', 'deps'], function (some, deps) {
//my code
return myThing;| { | |
| "curly": true, | |
| "eqeqeq": true, | |
| "immed": true, | |
| "latedef": false, | |
| "newcap": true, | |
| "noarg": true, | |
| "sub": true, | |
| "undef": true, | |
| "unused": true, |
This section describes the conventions used here to describe type signatures.
A [T] is an array-like value (only ever used read-only in this API), i.e., one with an integer length and whose indexed properties from 0 to length - 1 are of type T.
A type T? should be read as T | undefined -- that is, an optional value that may be undefined.
This section describes the conventions used here to describe type signatures.
A [T] is an array-like value (only ever used read-only in this API), i.e., one with an integer length and whose indexed properties from 0 to length - 1 are of type T.
A type T? should be read as T | undefined -- that is, an optional value that may be undefined.
This is an initial attempt at gathering together up to date resources on ES6 modules.
| /o/.toJSON || (RegExp.prototype.toJSON = function () { | |
| return [ | |
| this.source, | |
| (this.global ? "g" : "") + | |
| (this.ignoreCase ? "i" : "") + | |
| (this.multiline ? "m" : "") | |
| ]; | |
| }); | |
| var re = /test/g; | |
| alert(RegExp.apply(null, JSON.parse(JSON.stringify(re)))); |
