flow-typed: Flow-typed install crashes if you have a package installed from a git URL

This is regression the latest minor release - can work around by pinning to the previous version:

-    "flow-typed": "^2.5.1",
+    "flow-typed": "=2.5.1",

Still happens for me with 2.6.2 😦

Finally should be good now 😃

@pascalduez I confirmed that I have the code from #3537 in my installed version of flow-typed, it’s not fixing my issue, and I figured out exactly what’s going wrong.

Like @noahtallen, I have a preexisting stub sitting in flow-typed with this at the top:

// flow-typed version: <<STUB>>/babel-plugin-transform-import-commonjs_vhttps://github.com/jedwards1211/babel-plugin-transform-import-commonjs#patch-1-built/flow_v0.59.0

Here’s a cleaner stack trace than OP:

andy@Andys-MBP-2:clarity (observable-queries) $ flow-typed install zen-observable
Found delay listed twice in package.json!
• Searching for 1 libdefs...
• rebasing flow-typed cache...
UNCAUGHT ERROR: Error: Malformed npm package name! Expected the name to be formatted as <PKGNAME>_v<MAJOR>.<MINOR>.<PATCH> but instead got jedwards1211
    at parsePkgNameVer (/Users/andy/.config/yarn/global/node_modules/flow-typed/dist/lib/npm/npmLibDefs.js:179:11)
    at /Users/andy/.config/yarn/global/node_modules/flow-typed/dist/lib/npm/npmLibDefs.js:383:30
    at async Promise.all (index 28)
    at async getInstalledNpmLibDefs (/Users/andy/.config/yarn/global/node_modules/flow-typed/dist/lib/npm/npmLibDefs.js:345:5)
    at async installNpmLibDefs (/Users/andy/.config/yarn/global/node_modules/flow-typed/dist/commands/install.js:297:35)
    at async Object.run (/Users/andy/.config/yarn/global/node_modules/flow-typed/dist/commands/install.js:149:27)

getInstalledNpmLibDefs does this:

            const signedCodeVer = getSignedCodeVersion(fileContent);
            if (signedCodeVer === null) {
              return;
            }
            const matches = signedCodeVer.match(
              /([^\/]+)\/(@[^\/]+\/)?([^\/]+)\/([^\/]+)/,
            );
            if (matches == null) {
              return;
            }

            if (matches[1] === '<<STUB>>') {
              installedLibDefs.set(terseFilePath, {
                kind: 'Stub',
                name: matches[2],
              });
              return;
            }

But trying this out manually shows that <<STUB>> doesn’t get matched:

> var ver = '<<STUB>>/babel-plugin-transform-import-commonjs_vhttps://github.com/jedwards1211/babel-plugin-transform-import-commonjs#patch-1-built/flow_v0.59.0'
undefined
> var matches = ver.match( /([^\/]+)\/(@[^\/]+\/)?([^\/]+)\/([^\/]+)/)
undefined
> matches
[
  'github.com/jedwards1211/babel-plugin-transform-import-commonjs#patch-1-built',
  'github.com',
  undefined,
  'jedwards1211',
  'babel-plugin-transform-import-commonjs#patch-1-built',
  index: 57,
  input: '<<STUB>>/babel-plugin-transform-import-commonjs_vhttps://github.com/jedwards1211/babel-plugin-transform-import-commonjs#patch-1-built/flow_v0.59.0',
  groups: undefined
]

Better to just use signedCodeVer.startsWith('<<STUB>>') here, and also, we must make it tolerate/repair absolutely any bad preexisting version string.. Because it can’t control what was put there previously by bugs that have since been fixed.

any updates on #3537? that PR fixes this issue.

@knu, I just ran into this issue on 2.6.0. Pinning to 2.5.1 worked for me. It looks like git-based packages are (correctly?) skipping npmLibDefs.parsePkgNameVer in 2.5.1, but a quick look through commits around the 2.5.2 release hasn’t turned up any obvious culprits for the regression 😕