[email protected] requires git installed, fails otherwise.

[itsTeknas]

Our ci/cd failed because it seems like npm i --save [email protected] would fail if git is not installed on the server.
i have reverted back to 2.1.0 for now.

npm debug log for reference,

60 verbose stack Error: spawn git ENOENT
60 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
60 verbose stack     at onErrorNT (internal/child_process.js:469:16)
60 verbose stack     at processTicksAndRejections (internal/process/task_queues.js:84:21)
60 verbose stack From previous event:
60 verbose stack     at module.exports (/usr/local/lib/node_modules/npm/node_modules/pacote/lib/util/finished.js:6:13)
60 verbose stack     at /usr/local/lib/node_modules/npm/node_modules/pacote/lib/util/git.js:238:14
60 verbose stack     at /usr/local/lib/node_modules/npm/node_modules/promise-retry/index.js:29:24
61 verbose cwd /app
62 verbose Linux 4.19.76-linuxkit
63 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "i" "--save" "[email protected]"
64 verbose node v12.18.3
65 verbose npm  v6.14.6
66 error code ENOENT
67 error syscall spawn git
68 error path git
69 error errno ENOENT
70 error enoent Error while executing:
70 error enoent undefined ls-remote -h -t ssh://[email protected]/types/mysql.git
70 error enoent
70 error enoent
70 error enoent spawn git ENOENT
71 error enoent This is related to npm not being able to find a file.
72 verbose exit [ 1, true ]

[larshp]

suggest installing git on the server?

root cause: https://github.com/sidorares/node-mysql2/blob/master/package.json#L54 was added recently

@sidorares we could move the dependency to devDependencies, and rollup the typescript definition, if you like? I can help with a pull request for it

[sidorares]

yes, I think moving type definitions to dev dependency would be a good solution for this. Alternatively we could publish our own version of types/mysql or maybe even add it to a repo

I can help with a pull request for it

yes, that would be great if you can help

[pratik-sinha]

I am also facing this issue, it would be great if someone can find a solution for it

[larshp]

Running into a few issues microsoft/rushstack#2220, types/mysql#20

[normano]

Seems that the proper solution for any including of types/* package is to include as dev dependency which is only a package.json change.

[larshp]

Seems that the proper solution for any including of types/* package is to include as dev dependency which is only a package.json change.

I don't think that would work, node-mysql2 must export the types to be available for projects using the typescript definitions

[normano]

removed comment

[larshp]

cumbersome: yes, that's why this project started to move it into the package. Also see my suggestion above to rollup the definitions so there is no extra runtime or peer dependencies, and PR #1211 which contains a workaround by including the types in this project

[normano]

Actually, the original problem is that npm requires git in order to check out the types/mysql package. Since git is a valid dependency, the author of the issue should install git! Author is fine with 2.1.0 though.

Should not rush bundling any types until the maintainer has figured out where he wants to go with that.

[sidorares]

I personally feel bundling types ( at least for now ) is better option, gives me a bit more freedom with adding/removing types and at not a big cost in terms of package size

[itsTeknas]

Actually, the original problem is that npm requires git in order to check out the types/mysql package. Since git is a valid dependency, the author of the issue should install git! Author is fine with 2.1.0 though.

Should not rush bundling any types until the maintainer has figured out where he wants to go with that.

We are using docker,
dockerfile looks something like

FROM node:lts-slim
COPY . .
RUN npm install --only=production
EXPOSE 3000
CMD [ "node", "bin/www" ]

I don't think we have done something very different from most people.
npm install does work without any explicit git installation
this only started to fail after the library update.

[sidorares]

@itsTeknas [email protected] should work without git runtime

[sidorares]

you beat me by 2 seconds @larshp :)

[Bidthedog]

I'm a bit lost here I'm afraid, I don't have much experience with creating ES6 modules (though plenty importing) but I'm trying to get types in 2.2.5 working in a node.js app. I use the following import:

import { Connection, createConnection } from 'mysql2/promise';

And I'm using the following tsconfig.json:

{
  "compilerOptions": {
    "target": "ESNEXT",
    "module": "ESNext",
    "allowJs": false,
    "declaration": true,                      /* Generates corresponding '.d.ts' file. */
    "declarationMap": true,
    "sourceMap": true,
    "outDir": "./dist",
    "noImplicitAny": true,
    "strictNullChecks": true,                 /* Enable strict null checks. */
    "strictFunctionTypes": true,              /* Enable strict checking of function types. */
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "moduleResolution": "node",
    "baseUrl": "./",
    "typeRoots": [
      "node_modules/@types"
    ],
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    /* Experimental Options */
    "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */
    "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */

    /* Advanced Options */
    "skipLibCheck": true,                     /* Skip type checking of declaration files. */
    "forceConsistentCasingInFileNames": true  /* Disallow inconsistently-cased references to the same file. */
  },
  "include": [
    "./app/**/*.ts",
    "./index.ts"
  ],
  "exclude": [
    "./spec",
    "./node_modules",
    "./dist",
    "./**/*.spec.ts"
  ]
}

For my own app, that is.

And when I try to run the app after compiling with tsc, I get the following:

(node:5004) ExperimentalWarning: The ESM module loader is experimental.
file:///D:/Git/Personal/DNI/dni.bot/dist/app/services/db/adapters/mariaDb/mariaDbAdapter.js:2
import { createConnection } from 'mysql2/promise';
         ^^^^^^^^^^^^^^^^
SyntaxError: The requested module 'mysql2/promise' is expected to be of type CommonJS, which does not support named exports. CommonJS modules can be imported by importing the default export.
For example:
import pkg from 'mysql2/promise';
const { createConnection } = pkg;
    at ModuleJob._instantiate (internal/modules/esm/module_job.js:97:21)
    at async ModuleJob.run (internal/modules/esm/module_job.js:136:20)
    at async Loader.import (internal/modules/esm/loader.js:179:24)

Tried a few combinations without any success. Any advice?

[KiTiVi]

@Bidthedog I suggest changing your compiler options to:

"module": "CommonJS",
"target": "ES2017", (or ES2015 depending on Node version)

Thanks @sidorares and contributors/community for such a great package and fast development!

[itsTeknas]

The latest release works as expected
Thanks @sidorares and community, this was super fast.

[Bidthedog]

@Bidthedog I suggest changing your compiler options to:

"module": "CommonJS",
"target": "ES2017", (or ES2015 depending on Node version)

Thanks @sidorares and contributors/community for such a great package and fast development!

Thanks @KiTiVi - I did a lot of reading / googling last night and I actually changed it to the following and things seem to be working fine:

    "target": "ES2019",
    "module": "commonjs",
    "lib": [
      "es2019"
    ], 

Unfortunately a number of other things are broken in the app atm (I'm converting a fairly complex app from JS to TS) so I can't confirm that all the types are working for me yet... looking positive atm though :) I'll open another ticket if I hit any issues (and try to understand how the whole ecosystem sits together!).