Using ts-loader alongside Webpack is completely acceptable in our setup at Vue.js, where we operate on a large-scale multi-page SPA architecture with Webpack as our primary bundler. It's not necessary to create a separate configuration specifically for ts-loader. Here's a glimpse of our Webpack configuration showcasing three instances of ts-loader:
const rules = [
{
test: /\.tsx?$/,
loader: 'ts-loader',
include: [...PATHS.shared, path.join(__dirname, 'node_modules')],
options: {
transpileOnly: isDev,
appendTsSuffixTo: [/\.vue$/],
instance: 'common',
configFile: path.join(__dirname, 'tsconfig.json')
}
},
{
test: /\.tsx?$/,
loader: 'ts-loader',
include: [PATHS.app1],
options: {
transpileOnly: isDev,
appendTsSuffixTo: [/\.vue$/],
instance: 'app1',
configFile: path.join(PATHS.app1, 'tsconfig.json')
}
},
{
test: /\.tsx?$/,
loader: 'ts-loader',
include: [PATHS.app2],
options: {
transpileOnly: isDev,
appendTsSuffixTo: [/\.vue$/],
instance: 'app2',
configFile: path.join(PATHS.app2, 'tsconfig.json')
}
}
];
In response to your query, while I have found success using @babel/preset-typescript, it's important to note that we refrain from utilizing .vue files due to issues encountered during their processing which can be seen here. Note: During development, we set transpileOnly to false.
If feasible, transitioning to the class syntax combined with @Component decorator and integrating vue-template-loader could facilitate a switch to Babel + TypeScript. While making this transition, be mindful of limitations such as lack of support for features like const enums, namespaces, etc.
It should be noted that opting for ts-loader instead of @babel/preset-typescript comes with its own set of advantages. When paired with Webpack, ts-loader offers more flexibility. If typed JSX (TSX) compatibility is needed with Vue.js, then utilizing the babel approach might be more suitable. However, if you are working with .vue files, the difference may not be significant.