1 | # node-dashdash changelog
|
2 |
|
3 | ## not yet released
|
4 |
|
5 | (nothing yet)
|
6 |
|
7 | ## 2.0.0
|
8 |
|
9 | - [Backward incompatible change] This version drops official support for
|
10 | versions of node.js before 10.x. Dashdash 1.x supports back to node 0.10.x.
|
11 | I've no direct intention of breaking compat, but new changes won't be tested
|
12 | on older node versions. Moving to a newer node allows me to switch to a
|
13 | modernish node-tap for better testing.
|
14 |
|
15 | Dev changes:
|
16 | - Switch from nodeunit to node-tap for testing.
|
17 | - Switch from jsstyle to eslint for linting, and prettier for formatting.
|
18 | - Prefix release tags with a "v", e.g. "v2.0.0", as is I think more typical
|
19 | with other projects.
|
20 |
|
21 | ## 1.14.1
|
22 |
|
23 | - [issue #30] Change the output used by dashdash's Bash completion support to
|
24 | indicate "there are no completions for this argument" to cope with different
|
25 | sorting rules on different Bash/platforms. For example:
|
26 |
|
27 | $ triton -v -p test2 package get <TAB> # before
|
28 | ##-no -tritonpackage- completions-##
|
29 |
|
30 | $ triton -v -p test2 package get <TAB> # after
|
31 | ##-no-completion- -results-##
|
32 |
|
33 | ## 1.14.0
|
34 |
|
35 | - New `synopsisFromOpt(<option spec>)` function. This will be used by
|
36 | [node-cmdln](https://github.com/trentm/node-cmdln) to put together a synopsis
|
37 | of options for a command. Some examples:
|
38 |
|
39 | > synopsisFromOpt({names: ['help', 'h'], type: 'bool'});
|
40 | '[ --help | -h ]'
|
41 | > synopsisFromOpt({name: 'file', type: 'string', helpArg: 'FILE'});
|
42 | '[ --file=FILE ]'
|
43 |
|
44 |
|
45 | ## 1.13.1
|
46 |
|
47 | - [issue #20] `bashCompletionSpecFromOptions` breaks on an options array with
|
48 | an empty-string group.
|
49 |
|
50 |
|
51 | ## 1.13.0
|
52 |
|
53 | - Update assert-plus dep to 1.x to get recent fixes (particularly for
|
54 | `assert.optional*`).
|
55 |
|
56 | - Drop testing (and official support in packages.json#engines) for node 0.8.x.
|
57 | Add testing against node 5.x and 4.x with `make testall`.
|
58 |
|
59 | - [pull #16] Change the `positiveInteger` type to NOT accept zero (0).
|
60 | For those who might need the old behaviour, see
|
61 | "examples/custom-option-intGteZero.js". (By Dave Pacheco.)
|
62 |
|
63 |
|
64 | ## 1.12.2
|
65 |
|
66 | - Bash completion: Add `argtypes` to specify the types of positional args.
|
67 | E.g. this would allow you to have an `ssh` command with `argtypes = ['host',
|
68 | 'cmd']` for bash completion. You then have to provide Bash functions to
|
69 | handle completing those types via the `specExtra` arg. See
|
70 | "[examples/ddcompletion.js](examples/ddcompletion.js)" for an example.
|
71 |
|
72 | - Bash completion: Tweak so that options or only offered as completions when
|
73 | there is a leading '-'. E.g. `mytool <TAB>` does NOT offer options, `mytool
|
74 | -<TAB>` *does*. Without this, a tool with options would never be able to
|
75 | fallback to Bash's "default" completion. For example `ls <TAB>` wouldn't
|
76 | result in filename completion. Now it will.
|
77 |
|
78 | - Bash completion: A workaround for not being able to explicitly have *no*
|
79 | completion results. Because dashdash's completion uses `complete -o default`,
|
80 | we fallback to Bash's "default" completion (typically for filename
|
81 | completion). Before this change, an attempt to explicitly say "there are
|
82 | no completions that match" would unintentionally trigger filename completion.
|
83 | Instead as a workaround we return:
|
84 |
|
85 | $ ddcompletion --none <TAB> # the 'none' argtype
|
86 | ##-no completions-##
|
87 |
|
88 | $ ddcompletion # a custom 'fruit' argtype
|
89 | apple banana orange
|
90 | $ ddcompletion z
|
91 | ##-no -fruit- completions-##
|
92 |
|
93 | This is a bit of a hack, but IMO a better experience than the surprise
|
94 | of matching a local filename beginning with 'z', which isn't, in this
|
95 | case, a "fruit".
|
96 |
|
97 | ## 1.12.1
|
98 |
|
99 | - Bash completion: Document `<option spec>.completionType`. Add `includeHidden`
|
100 | option to `bashCompletionSpecFromOptions()`. Add support for dealing with
|
101 | hidden subcmds.
|
102 |
|
103 |
|
104 | ## 1.12.0
|
105 |
|
106 | - Support for generating Bash completion files. See the "Bash completion"
|
107 | section of the README.md and "examples/ddcompletion.js" for an example.
|
108 |
|
109 |
|
110 | ## 1.11.0
|
111 |
|
112 | - Add the `arrayFlatten` boolean option to `dashdash.addOptionType` used for
|
113 | custom option types. This allows one to create an `arrayOf...` option type
|
114 | where each usage of the option can return multiple results. For example:
|
115 |
|
116 | node mytool.js --foo a,b --foo c
|
117 |
|
118 | We could define an option type for `--foo` such that
|
119 | `opts.foo = ['a', 'b', 'c']`. See
|
120 | "[examples/custom-option-arrayOfCommaSepString.js](examples/custom-option-arrayOfCommaSepString.js)"
|
121 | for an example.
|
122 |
|
123 |
|
124 | ## 1.10.1
|
125 |
|
126 | - Trim the published package to the minimal bits. Before: 24K tarball, 144K unpacked.
|
127 | After: 12K tarball, 48K unpacked. `npm` won't let me drop the README.md. :)
|
128 |
|
129 |
|
130 | ## 1.10.0
|
131 |
|
132 | - [issue #9] Support `includeDefault` in help config (similar to `includeEnv`) to have a
|
133 | note of an option's default value, if any, in help output.
|
134 | - [issue #11] Fix option group breakage introduced in v1.9.0.
|
135 |
|
136 |
|
137 | ## 1.9.0
|
138 |
|
139 | - [issue #10] Custom option types added with `addOptionType` can specify a
|
140 | "default" value. See "examples/custom-option-fruit.js".
|
141 |
|
142 |
|
143 | ## 1.8.0
|
144 |
|
145 | - Support `hidden: true` in an option spec to have help output exclude this
|
146 | option.
|
147 |
|
148 |
|
149 | ## 1.7.3
|
150 |
|
151 | - [issue #8] Fix parsing of a short option group when one of the
|
152 | option takes an argument. For example, consider `tail` with
|
153 | a `-f` boolean option and a `-n` option that takes a number
|
154 | argument. This should parse:
|
155 |
|
156 | tail -fn5
|
157 |
|
158 | Before this change, that would not parse correctly.
|
159 | It is suspected that this was introduced in version 1.4.0
|
160 | (with commit 656fa8bc71c372ebddad0a7026bd71611e2ec99a).
|
161 |
|
162 |
|
163 | ## 1.7.2
|
164 |
|
165 | - Known issues: #8
|
166 |
|
167 | - Exclude 'tools/' dir in packages published to npm.
|
168 |
|
169 |
|
170 | ## 1.7.1
|
171 |
|
172 | - Known issues: #8
|
173 |
|
174 | - Support an option group *empty string* value:
|
175 |
|
176 | ...
|
177 | { group: '' },
|
178 | ...
|
179 |
|
180 | to render as a blank line in option help. This can help separate loosely
|
181 | related sets of options without resorting to a title for option groups.
|
182 |
|
183 |
|
184 | ## 1.7.0
|
185 |
|
186 | - Known issues: #8
|
187 |
|
188 | - [pull #7] Support for `<parser>.help({helpWrap: false, ...})` option to be able
|
189 | to fully control the formatting for option help (by Patrick Mooney) `helpWrap:
|
190 | false` can also be set on individual options in the option objects, e.g.:
|
191 |
|
192 | var options = [
|
193 | {
|
194 | names: ['foo'],
|
195 | type: 'string',
|
196 | helpWrap: false,
|
197 | help: 'long help with\n newlines' +
|
198 | '\n spaces\n and such\nwill render correctly'
|
199 | },
|
200 | ...
|
201 | ];
|
202 |
|
203 |
|
204 | ## 1.6.0
|
205 |
|
206 | - Known issues: #8
|
207 |
|
208 | - [pull #6] Support headings between groups of options (by Joshua M. Clulow)
|
209 | so that this code:
|
210 |
|
211 | var options = [
|
212 | { group: 'Armament Options' },
|
213 | { names: [ 'weapon', 'w' ], type: 'string' },
|
214 | { group: 'General Options' },
|
215 | { names: [ 'help', 'h' ], type: 'bool' }
|
216 | ];
|
217 | ...
|
218 |
|
219 | will give you this help output:
|
220 |
|
221 | ...
|
222 | Armament Options:
|
223 | -w, --weapon
|
224 |
|
225 | General Options:
|
226 | -h, --help
|
227 | ...
|
228 |
|
229 |
|
230 | ## 1.5.0
|
231 |
|
232 | - Known issues: #8
|
233 |
|
234 | - Add support for adding custom option types. "examples/custom-option-duration.js"
|
235 | shows an example adding a "duration" option type.
|
236 |
|
237 | $ node custom-option-duration.js -t 1h
|
238 | duration: 3600000 ms
|
239 | $ node custom-option-duration.js -t 1s
|
240 | duration: 1000 ms
|
241 | $ node custom-option-duration.js -t 5d
|
242 | duration: 432000000 ms
|
243 | $ node custom-option-duration.js -t bogus
|
244 | custom-option-duration.js: error: arg for "-t" is not a valid duration: "bogus"
|
245 |
|
246 | A custom option type is added via:
|
247 |
|
248 | var dashdash = require('dashdash');
|
249 | dashdash.addOptionType({
|
250 | name: '...',
|
251 | takesArg: true,
|
252 | helpArg: '...',
|
253 | parseArg: function (option, optstr, arg) {
|
254 | ...
|
255 | }
|
256 | });
|
257 |
|
258 | - [issue #4] Add `date` and `arrayOfDate` option types. They accept these date
|
259 | formats: epoch second times (e.g. 1396031701) and ISO 8601 format:
|
260 | `YYYY-MM-DD[THH:MM:SS[.sss][Z]]` (e.g. "2014-03-28",
|
261 | "2014-03-28T18:35:01.489Z"). See "examples/date.js" for an example usage.
|
262 |
|
263 | $ node examples/date.js -s 2014-01-01 -e $(date +%s)
|
264 | start at 2014-01-01T00:00:00.000Z
|
265 | end at 2014-03-29T04:26:18.000Z
|
266 |
|
267 |
|
268 | ## 1.4.0
|
269 |
|
270 | - Known issues: #8
|
271 |
|
272 | - [pull #2, pull #3] Add a `allowUnknown: true` option on `createParser` to
|
273 | allow unknown options to be passed through as `opts._args` instead of parsing
|
274 | throwing an exception (by https://github.com/isaacs).
|
275 |
|
276 | See 'allowUnknown' in the README for a subtle caveat.
|
277 |
|
278 |
|
279 | ## 1.3.2
|
280 |
|
281 | - Fix a subtlety where a *bool* option using both `env` and `default` didn't
|
282 | work exactly correctly. If `default: false` then all was fine (by luck).
|
283 | However, if you had an option like this:
|
284 |
|
285 | options: [ {
|
286 | names: ['verbose', 'v'],
|
287 | env: 'FOO_VERBOSE',
|
288 | 'default': true, // <--- this
|
289 | type: 'bool'
|
290 | } ],
|
291 |
|
292 | wanted `FOO_VERBOSE=0` to make the option false, then you need the fix
|
293 | in this version of dashdash.
|
294 |
|
295 |
|
296 | ## 1.3.1
|
297 |
|
298 | - [issue #1] Fix an envvar not winning over an option 'default'. Previously
|
299 | an option with both `default` and `env` would never take a value from the
|
300 | environment variable. E.g. `FOO_FILE` would never work here:
|
301 |
|
302 | options: [ {
|
303 | names: ['file', 'f'],
|
304 | env: 'FOO_FILE',
|
305 | 'default': 'default.file',
|
306 | type: 'string'
|
307 | } ],
|
308 |
|
309 |
|
310 | ## 1.3.0
|
311 |
|
312 | - [Backward incompatible change for boolean envvars] Change the
|
313 | interpretation of environment variables for boolean options to consider '0'
|
314 | to be false. Previous to this *any* value to the envvar was considered
|
315 | true -- which was quite misleading. Example:
|
316 |
|
317 | $ FOO_VERBOSE=0 node examples/foo.js
|
318 | # opts: { verbose: [ false ],
|
319 | _order: [ { key: 'verbose', value: false, from: 'env' } ],
|
320 | _args: [] }
|
321 | # args: []
|
322 |
|
323 |
|
324 | ## 1.2.1
|
325 |
|
326 | - Fix for `parse.help({includeEnv: true, ...})` handling to ensure that an
|
327 | option with an `env` **but no `help`** still has the "Environment: ..."
|
328 | output. E.g.:
|
329 |
|
330 | { names: ['foo'], type: 'string', env: 'FOO' }
|
331 |
|
332 | ...
|
333 |
|
334 | --foo=ARG Environment: FOO=ARG
|
335 |
|
336 |
|
337 | ## 1.2.0
|
338 |
|
339 | - Transform the option key on the `opts` object returned from
|
340 | `<parser>.parse()` for convenience. Currently this is just
|
341 | `s/-/_/g`, e.g. '--dry-run' -> `opts.dry_run`. This allow one to use hyphen
|
342 | in option names (common) but not have to do silly things like
|
343 | `opt["dry-run"]` to access the parsed results.
|
344 |
|
345 |
|
346 | ## 1.1.0
|
347 |
|
348 | - Environment variable integration. Envvars can be associated with an option,
|
349 | then option processing will fallback to using that envvar if defined and
|
350 | if the option isn't specified in argv. See the "Environment variable
|
351 | integration" section in the README.
|
352 |
|
353 | - Change the `<parser>.parse()` signature to take a single object with keys
|
354 | for arguments. The old signature is still supported.
|
355 |
|
356 | - `dashdash.createParser(CONFIG)` alternative to `new dashdash.Parser(CONFIG)`
|
357 | a la many node-land APIs.
|
358 |
|
359 |
|
360 | ## 1.0.2
|
361 |
|
362 | - Add "positiveInteger" and "arrayOfPositiveInteger" option types that only
|
363 | accept positive integers.
|
364 |
|
365 | - Add "integer" and "arrayOfInteger" option types that accepts only integers.
|
366 | Note that, for better or worse, these do NOT accept: "0x42" (hex), "1e2"
|
367 | (with exponent) or "1.", "3.0" (floats).
|
368 |
|
369 |
|
370 | ## 1.0.1
|
371 |
|
372 | - Fix not modifying the given option spec objects (which breaks creating
|
373 | a Parser with them more than once).
|
374 |
|
375 |
|
376 | ## 1.0.0
|
377 |
|
378 | First release.
|