Imported es6 module is undefined during Debug (During Test Runs)

Prod code:

I'm using ts-node to compile my tests.  I've wired my test config to compiler.ts which wires up my project to ts-node.

Enabling sourceMaps in my tsconfig.json; adding the line:

"sourceMap": true

 did nothing for me to resolve this.  I'm running my tests on the .ts files not .js files anyway...so that doesn't make any sense to enable source maps if I run my tests on .ts files regardless I don't think.

Besides I was able to debug other variables or modules just fine during debug time without any of trying this.  It was just for some reason this particular module it's not letting me interact with it during debug.

compiler.ts

require('ts-node').register({
project: './src/test/graphql/tsconfig.json',
});

tsconfig.json

{
"compilerOptions": {
"noEmit": false,
"rootDir": ".",
"outDir": "../../dist/graphql",
"esModuleInterop": true,
"lib": ["esnext"]
},
"include": ["./*.ts", "package.json"],
"exclude": ["/src/test/**/*"],
"resolveJsonModule": true
}

I don't understand why inMemoryDb is undefined when I debug and put breakpoints either in my tests OR prod code; hitting the debug points should show inMemoryDb having an instance already.

The inMemoryDb module works fine when I run my code so why in debug mode am I getting undefined for it? 

It prevents me from using the evaluation tool to play with it during debug and query my in-memory DB to check stuff in the DB when I need to.

Aside: also getting very tired of this editor losing syntactic highlighting, when will JetBrains finally fix their terrible forum editor.

This has nothing to do with webpack.  I am running tests on a GraphQL service.

InMemoryDB.ts

import { newDb } from 'pg-mem';
import fs from 'fs';

const inMemoryDb = newDb();
inMemoryDb.public.none(fs.readFileSync('src/graphql/DB/pgMem/migrations/001-initial.sql', 'utf8'));
export default inMemoryDb;

some.spec.ts

import inMemoryDb from '../../../../graphql/DB/pgMem/InMemoryDB';

describe('Crafter Read', () => {
beforeEach(() => {
inMemoryDb.backup(); //putting a debug point here and hitting it, shows inMemoryDb undefined
});
...


Now what's interesting if I go back to what I had a long time ago, it was this, and this allowed me to get the in memory DB instance just fine during test debugs when I used it this way (no sourcemaps were enabled):

let dbInstance;

const PgMemDb = () => {
function getInstance() {
if (!dbInstance) {
const db = newDb();
db.public.none(fs.readFileSync('src/DB/pgMem/migrations/001-initial.sql', 'utf8'));
dbInstance = db;
}
return dbInstance;
}
return {
getInstance,
};
};

export default PgMemDb;

and then in my tests or prod code using it like this


beforeEach(() => {
// inMemoryDb.backup();
const pgmemDb = PgMemDb().getInstance();
pgmemDb.backup();
});

so I don't understand when I simplified this module to my first example, why WebStorm can no longer get access to the pg mem db instance created by newDb()

0
7 comments

Undefined variables while debugging must be caused by wrong/missing name mappings in sourcemaps: if the variable is renamed while transpiling/obfuscating, and no appropriate name mapping is provided, the debugger won't be able to match variable in source code with the one in VM.

For example, import somefunction from './somefunc' is usually compiled to

Object.defineProperty(exports, "__esModule", { value: true });
var somefunc_1 = require("./somefunc");
somefunc_1.default();

if no name mappings are generated ("names":[] in generated sourcemap), the debugger can't match the variable in .ts file with the code in runtime and shows undefined

Tickets that can be related: https://github.com/microsoft/TypeScript/issues/9627, https://github.com/webpack/webpack/issues/3957, https://github.com/babel/babel/issues/1468

0

So I wrote that I'm not even using sourcemaps.  The later example works without sourcemaps by wrapping the same code before in more function scopeWhy is that? 

 

I've already looked at all those links in fact.  They don't relate to my situation.

All I did different was wrap the same code essentially that was in the first example, in a function or two and somehow WebStorm was able to give me the DB instance.  This has nothing to do with sourcemaps as they're turned completely off for all of my code and I've always been able to debug just fine without them.

 

My tests are running on .ts files.  The files that tsconfig.json generates has no sourcemaps whatsoever, I've never needed to turn that on.  I've always gotten debugging on my code without sourcemaps enabled for tsconfig.

0

>So I wrote that I'm not even using sourcemaps.

You are using them. Typescript can't be executed directly, it has to be transpiled. And the only way to map original sources to the generated .js files during debugging is using sourcemaps; if they were not there, breakpoints in .ts files would never be hit.

 

1

the only place I see sourcemaps set is here.  But it's not generating physical sourcemap files in my dist folder which is where tsconfig outputs to.  So if it's not generating sourcemap files anywhere (I looked everwhere) and you say it's a must then how in the world am I still able to debug...because I am able to debug.

0

Ok so again, I had no source maps, was able to debug.  No idea how.  Anyway, moving on, so I enabled sourcemaps.  And still, I get no instance for my in-memory DB:

the sourcemap:

Still don't get the instance during debug:

Your thoughts again please on these 3:

1) I didn't originally see sourcemap files so how in the world was I able to debug these last few months
2) how come now that I do have sourcemaps, clearly, I am still not able to get that instance of the in-memory DB during debug
3) Why did this code without creating sourcemaps give me the db instance:

let dbInstance;

const PgMemDb = () => {
function getInstance() {
if (!dbInstance) {
const db = newDb();
db.public.none(fs.readFileSync('src/DB/pgMem/migrations/001-initial.sql', 'utf8'));
dbInstance = db;
}
return dbInstance;
}
return {
getInstance,
};
};

export default PgMemDb;
0

Another thing I noticed is with or without sourcemaps (either way), this variation of the first example below, seemed to give me the DB instance when I mouse over it now, BUT, when I tried to use in the evaluator, it then showed it is undefined.

So...Below example: exported it not as a default export for some reason allowed me to seemingly get the instance when I moused over the instance during debug

const inMemoryDb = newDb();
inMemoryDb.public.none(fs.readFileSync('src/graphql/DB/pgMem/migrations/001-initial.sql', 'utf8'));
export { inMemoryDb };

so when I mouse over now I don't see undefined:

BUT, when I try to use it it's undefined - like 🤷‍♂️🤷‍♂️

0

> So if it's not generating sourcemap files anywhere (I looked everwhere) and you say it's a must then how in the world am I still able to debug...because I am able to debug.

you do have sourcemaps, they are generated by ts-node on-the-fly; you won't be able to debug otherwise

>Why did this code without creating sourcemaps give me the db instance

the problem is specific to the way import statements are transpiled, that's why you don't see issues when not trying to evaluate the imported module

0

Please sign in to leave a comment.