Recently, I introduced tiptap-vuetify as a dependency in my Vue application, triggering the addition of 19 other modules as transitive dependencies. After integrating it, I proceeded to run my tests only to encounter the following error:
Jest encountered an unexpected token
This error typically arises when attempting to import a file that Jest is unable to interpret, such as a non-plain JavaScript file.
By default, Jest utilizes a Babel configuration for file transformation, with the exclusion of "node_modules".
To resolve this issue, consider the following options:
• Specify a custom "transformIgnorePatterns" in your configuration to transform certain "node_modules" files.
• If a custom transformation is required, define a "transform" option in your configuration.
• To mock non-JS modules, such as binary assets, utilize the "moduleNameMapper" config option.
For detailed information and examples of these configuration options, refer to the documentation:
https://jestjs.io/docs/en/configuration.html
SyntaxError: Unexpected token 'export'
at ScriptTransformer._transformAndBuildScript (node_modules/@jest/transform/build/ScriptTransformer.js:537:17)
at ScriptTransformer.transform (node_modules/@jest/transform/build/ScriptTransformer.js:579:25)
at node_modules/tiptap-vuetify/dist/bundle-umd.js:1:112
at Object.<anonymous> (node_modules/tiptap-vuetify/dist/bundle-umd.js:1:2)
It appears that tiptap-vuetify contains code that requires transpilation by Jest. As mentioned in the Jest documentation, adding the following snippet to the jest.config.js
file should address the issue if the untranspiled code resides in either tiptap or tiptap-vuetify:
transformIgnorePatterns: [
"node_modules/(?!(tiptap-vuetify|tiptap)/)"
]
Despite implementing this solution, the problem persisted. As an alternative approach, I tried the following adjustment:
transformIgnorePatterns: ['/node_modules/tiptap.*']
Subsequently, the issue no longer persisted. However, I suspect that I am now transpiling my entire dependency tree, leading to longer test execution times. Is there a more efficient resolution to this predicament?