Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mysql2@2.2.3 requires git installed, fails otherwise. #1210

Closed
itsTeknas opened this issue Sep 21, 2020 · 17 comments
Closed

mysql2@2.2.3 requires git installed, fails otherwise. #1210

itsTeknas opened this issue Sep 21, 2020 · 17 comments

Comments

@itsTeknas
Copy link

Our ci/cd failed because it seems like npm i --save mysql2@2.2.3 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" "mysql2@2.2.3"
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://git@github.com/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
Copy link
Contributor

larshp commented Sep 21, 2020

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
Copy link
Owner

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
Copy link

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

@larshp
Copy link
Contributor

larshp commented Sep 21, 2020

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

@normano
Copy link
Contributor

normano commented Sep 21, 2020

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
Copy link
Contributor

larshp commented Sep 21, 2020

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
Copy link
Contributor

normano commented Sep 21, 2020

removed comment

@larshp
Copy link
Contributor

larshp commented Sep 21, 2020

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
Copy link
Contributor

normano commented Sep 21, 2020

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

@itsTeknas mysql2@2.2.4 should work without git runtime

@sidorares
Copy link
Owner

you beat me by 2 seconds @larshp :)

@Bidthedog
Copy link

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
Copy link

KiTiVi commented Sep 21, 2020

@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
Copy link
Author

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

@Bidthedog
Copy link

@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!).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants