jest-dynamodb
jest-dynamodb copied to clipboard
Breakage updating to 3.3.0
Sorry this bug report is incomplete, I'm just filing what I have now until I can look into it later.
After updating from 3.2.0 to 3.3.0 I get the following errors:
$ jest --runInBand
● Validation Warning:
Unknown option "default" with value {"globalSetup": "/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/setup.js", "globalTeardown": "/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/teardown.js", "testEnvironment": "/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/environment.js"} was found.
This is probably a typing mistake. Fixing it will remove this message.
Configuration Documentation:
https://jestjs.io/docs/configuration
● Validation Warning:
Unknown option "default" with value {"globalSetup": "/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/setup.js", "globalTeardown": "/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/teardown.js", "testEnvironment": "/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/environment.js"} was found.
This is probably a typing mistake. Fixing it will remove this message.
Configuration Documentation:
https://jestjs.io/docs/configuration
FAIL src/changes/changes-stack.change-handler.messages.test.ts
● change handler › test
AWS SDK error wrapper for Error: connect ECONNREFUSED 127.0.0.1:8090
@harazdovskiy could you please take a look? Likely a problem with export default
vs export
(just a guess)?
Sorry again about the minimal bug report. I hope to have time to look into this tomorrow or the next day to provide more details.
I think this comes down to:
const preset = require('./lib');
needing to specify .default
before re-exporting the result.
My working
For the validation warnings, the stack I get is:
at logValidationWarning (/home/birtles/project/node_modules/jest-validate/build/utils.js:101:11)
at Object.unknownOptionWarning [as unknown] (/home/birtles/project/node_modules/jest-validate/build/warnings.js:44:35)
at _validate (/home/birtles/project/node_modules/jest-validate/build/validate.js:81:17)
at validate (/home/birtles/project/node_modules/jest-validate/build/validate.js:118:41)
at normalize (/home/birtles/project/node_modules/@jest/core/node_modules/jest-config/build/normalize.js:645:65)
at readConfig (/home/birtles/project/node_modules/@jest/core/node_modules/jest-config/build/index.js:219:74)
at async readConfigs (/home/birtles/project/node_modules/@jest/core/node_modules/jest-config/build/index.js:404:26)
at async runCLI (/home/birtles/project/node_modules/@jest/core/build/cli/index.js:140:59)
at async Object.run (/home/birtles/project/node_modules/jest-cli/build/cli/index.js:155:37)
The options passed in to normalize
are:
{
transform: { '^.+\\.tsx?$': 'ts-jest' },
default: {
globalSetup: '/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/setup.js',
globalTeardown: '/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/teardown.js',
testEnvironment: '/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/environment.js'
},
testMatch: [ '**/*.test.ts' ],
modulePathIgnorePatterns: [ '.aws-sam', 'cdk.out' ],
moduleNameMapper: {
'@birchill/bugsnag-zero/lambda-context': '@birchill/bugsnag-zero/lambda-context-cjs'
},
rootDir: '/home/birtles/project'
}
Digging into readConfig
we are hitting this branch withconfigPath
being /home/birtles/project/jest.config.js
, and rawOptions
being the above object.
That's coming from calling requireOrImportModule
here:
https://github.com/facebook/jest/blob/main/packages/jest-config/src/readConfigFileAndSetRootDir.ts#L40
The requires the config file here:
https://github.com/facebook/jest/blob/main/packages/jest-util/src/requireOrImportModule.ts#L22
applyInteropRequireDefault
is true so it ends up wrapping the object in { default: <config> }
before accessing the default
property anyway. No problem here.
The problem is why the config
file has the globalSetup
etc. members nested under default
.
Looking at my config file I have:
const tsPreset = require('ts-jest/jest-preset');
const dynamodbPreset = require('@shelf/jest-dynamodb/jest-preset');
module.exports = {
...tsPreset,
...dynamodbPreset,
testMatch: ['**/*.test.ts'],
transform: {
'^.+\\.tsx?$': 'ts-jest',
},
modulePathIgnorePatterns: ['.aws-sam', 'cdk.out'],
};
Here tsPreset
is:
{ transform: { '^.+\\.tsx?$': 'ts-jest' } }
while dynamodbPreset
is:
dynamodbPreset {
default: {
globalSetup: '/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/setup.js',
globalTeardown: '/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/teardown.js',
testEnvironment: '/home/birtles/project/node_modules/@shelf/jest-dynamodb/lib/environment.js'
}
}
In jest-preset.js
where we have:
const preset = require('./lib');
module.exports = preset;
preset
is being resolved to:
{
default: {
globalSetup: '/home/birtles/10ten-server/node_modules/@shelf/jest-dynamodb/lib/setup.js',
globalTeardown: '/home/birtles/10ten-server/node_modules/@shelf/jest-dynamodb/lib/teardown.js',
testEnvironment: '/home/birtles/10ten-server/node_modules/@shelf/jest-dynamodb/lib/environment.js'
}
}
I'm way out of my depth when it comes to module loading but just going off the explanation here on this SO answer and digging into lib/index.js
, I wonder if we want to be doing:
const preset = require('./lib').default;
instead?
That seems to line up with this SO answer too.
If so, that would make b073618a93b0bfaee92c787b72dfd70ab17ea305 the culprit.
Just changing:
const preset = require('./lib');
to:
const preset = require('./lib').default;
locally fixes it for me.
@birtles Thanks for pointing out this issue, v3.3.1 was released with your fix!
Thank you!