Fix typescript intellisense

[Martoxdlol]

VS Code wasn't recognizing TypeScript.
I added "types" key to the package.json.
It shouldn't change how anything works, but it does allow VS Code to recognize types correctly.

[mathe42]

@Martoxdlol just add moduleResolution: "Node16" in your tsconfig!

[Chooks22]

@mathe42 at this point we should probably add this fallback type for default setups, it'd be easier to tell users to update their tsconfig if they want to resolve types for subpath imports down the line.

[Martoxdlol]

@Martoxdlol just add moduleResolution: "Node16" in your tsconfig!

I tried that in a new TS project and it didn't works

index.ts

import Surreal from 'surrealdb.js'

new Surreal()

VS Code error

The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("surrealdb.js")' call instead.
To convert this file to an ECMAScript module, change its file extension to '.mts', or add the field "type": "module" to '/home/coder/node_project/package.json'.

tsconfg.json

{
    "compilerOptions": {
        "moduleResolution": "node16"
    }
}

package.json

{
  "name": "node_project",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "surrealdb.js": "^0.4.0"
  }
}

[mathe42]

use type: "module" in your package.json or use require('surrealdb.js') to import the client.

[Martoxdlol]

use type: "module" in your package.json or use require('surrealdb.js') to import the client.

Thanks, that works. I took a sec to update the error but its working now.

[mathe42]

@mathe42 at this point we should probably add this fallback type for default setups, it'd be easier to tell users to update their tsconfig if they want to resolve types for subpath imports down the line.

Before working on surrealdb.js I would agree but I think the Node16 option is much better and gives us so much more options!

I think we should keep it but document it properly.

[Martoxdlol]

@mathe42 at this point we should probably add this fallback type for default setups, it'd be easier to tell users to update their tsconfig if they want to resolve types for subpath imports down the line.

Before working on surrealdb.js I would agree but I think the Node16 option is much better and gives us so much more options!

I think we should keep it but document it properly.

The Node16 option is breaking a existing project imports. I'm not an expert in how exactly module resolution works with different configurations. I will research it and see what can i do.

[Chooks22]

The Node16 option makes it so that typescript is able to resolve types from the exports fields and not just from types, not entirely sure how that would be able to break imports since it'll still use main and types as fallback 🤔

There's the old typesVersions hack for typing subpath imports without Node16, but it's rather janky.

[Martoxdlol]

Using Node16 its forcing to import typescript files with .js

[Chooks22]

Typescript here is wrong, we have the proper .cjs extensions so that it will resolve properly for commonjs users...

I reckon we should just switch to commonjs default + .mjs esm build.

[Martoxdlol]

I failed making it work. It only worked for me changing the package.json of surrealdb.js. For now I will use my modified fork.
thanks for your time!

[Martoxdlol]

use type: "module" in your package.json or use require('surrealdb.js') to import the client.

It works using require('surrealdb.js') but doesn't recognize types.

[btmnk]

If I'm not mistaken it will only load the cjs output when using require as it is defined like that in the package.json:

 "exports": {
    ".": {
      "import": "./dist/esm/index.js",
      "require": "./dist/cjs/index.cjs",
      "types": "./dist/types/index.d.ts"
    }
  }

To use the import syntax the developers are forced to convert their project to ESM.
ESM projects require to use .js file endings even though you're using typescript (Which will still work fine, it just looks weird).
I think this only works without file endings in deno?

[Chooks22]

@Martoxdlol uh, should I have made another pr here instead of continuing from your pr?

@btmnk by default, typescript uses es module syntax but still uses node's module resolution algorithm (implicit .js and /index.js, etc) so .js extensions would still work.

[Martoxdlol]

@Martoxdlol uh, should I have made another pr here instead of continuing from your pr?

Nono, its ok.
With this pr it works for me and my already existing project, adding "types": "./dist/types/index.d.ts" in package.json solved it for me.
I don't have much experience contributing to projects. But I thinks there is no problem continuing this pull request.

[btmnk]

@Choooks22 I just wanted to clarify that it's normal to use .js file extensions in esm projects when the moduleResolution is set to Node16 or NodeNext even when using typescript.

But there is still the issue that you can't import the lib in a commonjs project with the import statement.

The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("surrealdb.js")' call instead.
  To convert this file to an ECMAScript module, change its file extension to '.mts', or add the field `"type": "module"` to '/home/btmnk/development/surreal-playground/cjs-with-import/package.json'.

Not sure if this was intended..
Would probably make sense to put into another issue/pr if this is relevant

// EDIT:
I've created a small repo with all 3 cases to showcase the issues if it helps: https://github.com/btmnk/surreal-playground

[Martoxdlol]

@Choooks22 I tried your repo

cjs-with-require
Import error and failed to start

The current file is a CommonJS module whose imports will produce 'require' calls ...

cjs-with-require
Works fine, but doesn't recognize TS types and doesn't have intellisense.

esm-with-import
Works fine and have types but importing other ts files must be done using .js

[Martoxdlol]

javascript/typescript are so complicated
There should be a way that things just work

[mathe42]

FYI I'm happy whatever you change for that - as long as it works. I (personaly) think that we should bundle the TS files into a single file. That would reduce most of the problems. (I personaly think the same about all build files this incluides esm an cjs).

I think commonjs is getting completly replaced in the next 1-2 years so we might even remove the cjs build (personal opinion!).

[Martoxdlol]

FYI I'm happy whatever you change for that - as long as it works. I (personaly) think that we should bundle the TS files into a single file. That would reduce most of the problems. (I personaly think the same about all build files this incluides esm an cjs).

I think commonjs is getting completly replaced in the next 1-2 years so we might even remove the cjs build (personal opinion!).

I agree with that

[Chooks22]

cc @btmnk

cjs-with-require
Import error and failed to start

tsconfig had module: ES6 while not setting type: module in package.json nor using .mjs extension, it should have been module: commonjs to actually have commonjs output.

cjs-with-require
Works fine, but doesn't recognize TS types and doesn't have intellisense.

That's because typescript automatically drops types when you use require()...

esm-with-import
Works fine and have types but importing other ts files must be done using .js

This was the only repro that had proper settings and emitted files, and yes ES modules requires the .js extension.

---

Please note that while typescript does use ES module syntax, it doesn't mean that the emitted javascript files are ES modules. If the target is ES5 or ES3 or module is explicitly set to commonjs, it will transpile static imports to use require(), meaning typescript ESM syntax != javascript ESM runtime (unless properly configured).

Also, while this error does get emitted when running tsc:

The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("surrealdb.js")' call instead.
  To convert this file to an ECMAScript module, change its file extension to '.mts', or add the field `"type": "module"` to '/home/chooks/code/surreal-playground/cjs-with-import/package.json'.

It works totally fine when you run the emitted javascript file, since we do have proper entrypoints. This should be a typescript compiler issue.

Edit: just found a very relevant issue at microsoft/TypeScript#50794.

I've resolved these errors at Martoxdlol#1 and just waiting for merge.

Update: I've found some blocking issues that would need updating...

[oberbeck]

Do we have an update on this?

[mathe42]

I prefere #40 to be merged.