Because the bundle contains some *.ts files, the component tests webpack tries to parse them (probably because when they're internally imported, the default references are for .ts files, not .js files).
ERROR in ../../node_modules/cypress-terminal-report/src/collector/LogCollectControlExtended.ts 5:12
Module parse failed: Unexpected token (5:12)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| import utils from "../utils";
| import LogCollectorState from "./LogCollectorState";
> import type {ExtendedSupportOptions} from "../installLogsCollector.types";
| import type {MessageData} from "../types";
|
ERROR in ../../node_modules/cypress-terminal-report/src/collector/LogCollectCypressCommand.ts 9:33
Module parse failed: Unexpected token (9:33)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
|
| register() {
> const isOfInterest = (options: any) => options.instrument === 'command' &&
| options.consoleProps &&
| !this.ignoredCommands.includes(options.name) &&
The above doesn't occur when webpack's ts-loader is configured to NOT exclude node_modules, but that's a bad practice from the performance point of view. Such a config can interfere with other dependencies.
I don't think those TS files are needed in the released bundle, and I believe they can be safely removed.
Because the bundle contains some *.ts files, the component tests webpack tries to parse them (probably because when they're internally imported, the default references are for .ts files, not .js files).
The above doesn't occur when webpack's ts-loader is configured to NOT exclude
node_modules
, but that's a bad practice from the performance point of view. Such a config can interfere with other dependencies.I don't think those TS files are needed in the released bundle, and I believe they can be safely removed.