Type Checking In Non TS Files

[Skillz4Killz]

This error appears when you add DenoDB into a project with i18next, or vice versa. I have had several users report this issue when using Discordeno lib. At first, my module works fine but once they add DenoDB it breaks. Both projects work fine separtely but putting them together seems to make Deno process non TS files as if they are TS files.

error: Uncaught TypeError: TS2580 [ERROR]: Cannot find name 'require'. Do you need to install type definitions for node? Try `npm i @types/node`.
if (typeof require !== 'undefined') {
           ~~~~~~~
    at https://deno.land/x/i18next_fs_backend@v1.0.8-rc.1/lib/fs.cjs:1:12

TS2580 [ERROR]: Cannot find name 'require'. Do you need to install type definitions for node? Try `npm i @types/node`.
  var f = require('fs')
          ~~~~~~~
    at https://deno.land/x/i18next_fs_backend@v1.0.8-rc.1/lib/fs.cjs:2:11

TS2304 [ERROR]: Cannot find name 'exports'.
  exports.default = f
  ~~~~~~~
    at https://deno.land/x/i18next_fs_backend@v1.0.8-rc.1/lib/fs.cjs:4:3

TS2580 [ERROR]: Cannot find name 'module'. Do you need to install type definitions for node? Try `npm i @types/node`.
  module.exports = exports.default
  ~~~~~~
    at https://deno.land/x/i18next_fs_backend@v1.0.8-rc.1/lib/fs.cjs:5:3

TS2304 [ERROR]: Cannot find name 'exports'.
  module.exports = exports.default
                   ~~~~~~~
    at https://deno.land/x/i18next_fs_backend@v1.0.8-rc.1/lib/fs.cjs:5:20

Relevant: i18next/i18next-fs-backend#11 eveningkid/denodb#100

Note: This might have something to do with dynamic importing:

Ah! The hash is messing up the extension detection. That's a bug.

[nayeemrmn]

This will likely be fixed by #6894.

[kitsonk]

Yes, the current problem arises when there are transitory dependencies in JS that are loading TypeScript. When this occurs, the current implementation turns on checkJs in order to get tsc to try to compile all the TypeScript. We need to basically spoon feed the compiler all the TypeScript when the checkJs isn't being set by the user.

[Skillz4Killz]

@kitsonk @nayeemrmn Please, can anyone update whats the status of this issue? #6894 was closed.

[kitsonk]

It was replaced by #7225 which the first step is #7621 and then will be followed by other PRs.

[kitsonk]

This will be fixed in #7996... it ended up being far more complex than it appeared...

We needed to do two things... be explicit about the ts.ScriptKind when creating new source files. While we were setting the ts.Extension when resolving modules names, thinking that was sufficient, sometimes TypeScript would end up guessing at this anyways, then looking at the module name, and erring on the side of it being potentially TypeScript. Also, TypeScript "helpfully" tries to transform any JavaScript it thinks looks like CommonJS to ESM. So we need to also ignore that when we are not checking JS, which is what causes some problems with consuming packages from JSPM.io which wraps a converter as part of the bundle it serves.

[kitsonk]

I believe this is fixed.