fix: -- (stop parse) was not being respected by commands

[bcoe]

@evocateur I believe this addresses at least half of the issues you described in #1457 (it sounded like you were potentially describing two bugs).

mind trying the branch out?

fixes #1457

[evocateur]

This appears to also solve the other issue I hinted at in #1457, complaining about unknown arguments past the --. LGTM, sad it won't get into v14 though :/

[evocateur]

Here's the test I wrote locally to validate the weird strict() + options passed after --:

diff --git a/test/validation.js b/test/validation.js
index bd0bd1d..e9dc0d6 100644
--- a/test/validation.js
+++ b/test/validation.js
@@ -848,6 +848,19 @@ describe('validation tests', () => {
       args.foo.should.equal(true)
       args.bar.should.equal(true)
     })
+
+    it('does not fail when unrecognized option is passed after --', () => {
+      const args = yargs('ahoy ben -- --arrr')
+        .strict()
+        .command('ahoy <matey>', 'piratical courtesy')
+        .option('arrr', { boolean: true, describe: false })
+        .fail((msg) => {
+          expect.fail(msg)
+        })
+        .parse()
+      args.matey.should.equal('ben')
+      args._.should.deep.equal(['ahoy', '--arrr'])
+    })
   })
 
   describe('demandOption', () => {

[bcoe]

@evocateur I will try to back-port into 14, if it applies cleanly.

[bcoe]

@evocateur please go ahead and test with npm i yargs@next-14, I will have v15 out relatively soon.

[bcoe]

@evocateur when you have a moment, could you try npm i yargs@next and see if your issue has been addressed?

[evocateur]

@bcoe Sorry for the delay. I think we have a problem :(

Both v14.2.1 and v15.0.0 fail across all platforms in lerna@latest:

• yargs-14-next (travis)
• yargs-next (travis)

The most common error is TypeError: Cannot delete property '--' of #<Object>, stack points to this line. The other test failures seem to be related to "known" flags after an unknown positional being swallowed incorrectly.

Running the integration tests (npm run integration, which don't use the artificial ./helpers/command-runner, but call lerna as a proper CLI via execa), we encounter the same TypeError: Cannot delete property '--' of #<Object>:

 FAIL  integration/lerna-run-since.test.js
  ● lerna run --since

    Command failed: node /Users/daniels/github/lerna/core/lerna/cli.js run test --since --concurrency=1 -- --silent
    /Users/daniels/github/lerna/node_modules/yargs/yargs.js:1183
          else throw err
               ^

    TypeError: Cannot delete property '--' of #<Object>

      42 |     .command(runCmd)
      43 |     .command(versionCmd)
    > 44 |     .parse(argv, context);
         |      ^
      45 | }
      46 |

      at Object.Yargs.self._copyDoubleDash (node_modules/yargs/yargs.js:1195:5)
      at Object.parseArgs [as _parseArgs] (node_modules/yargs/yargs.js:1096:60)
      at Object.parse (node_modules/yargs/yargs.js:583:25)
      at main (core/lerna/index.js:44:6)
      at Object.<anonymous> (core/lerna/cli.js:11:15)
      at makeError (node_modules/execa/index.js:174:9)
      at Promise.all.then.arr (node_modules/execa/index.js:278:16)

(this is output from the branch using yargs@15, but it's the same error with yargs@14.2.1)

The test failures are all in modules that explicitly specify yargs.parserConfiguration({ "populate--": true }) in their command builder (it's never set globally). When removing it, say, from the version command, the tests for that module pass. This "works" for the version command, but others like lerna run and lerna exec depend on "populate--": true.

[NoahZinsmeister]

My lerna@3.18.4 package is also broken in the same way (implicit yargs@14.2.1 dependency)

[bcoe]

@evocateur @NoahZinsmeister can you send a failing test? to me this seems like another dependency in lerna is mucking with object definitions:

> const obj = {}
undefined
> delete obj['--']
true
> 

Is there another dependency which is potentially mucking with object creation?

[NoahZinsmeister]

possibly @bcoe ! the best i can do atm is give you the steps i'm doing to reproduce the bug locally:

• git clone https://github.com/NoahZinsmeister/web3-react.git
• git checkout a3cc8515451594c5015627a7f235bb8aa410b2a9
• yarn
• yarn start