Without an outDir specified, accidental tsc will result in the package being littered with js/js.map files about ts-monorepo HOT 6 CLOSED

Using references and dropping the build tsconfig files seems to be the way to go.

The only caveat is that I've had issues getting ts-loader / tsconfig-paths-webpack-plugin to populate. tsconfig-paths works though.

https://github.com/chanced/ts-monorepo

from ts-monorepo.

You shouldn't need to use composite in the main tsconfig.json that gets picked up by your IDE, therefore you could add noEmit: true in that one and then disable it in the tsconfig.build.json. Similarly with outDir, it should be OK to have it in the main config as long as it's set to the proper path in the build config.

from ts-monorepo.

You're right, I didn't consider that. I'm not sure why I had composite on the root package anyway.

Having said that, I still think using references is the way to go though. It eliminates the need for the build files and makes the build process faster.

I'm just running into issues with ts-loader not liking the fact that ts-config-paths-webpack-plugin is proposing files outside of the rootDir. I'm not sure why the way I constructed mine would be too different than yours.

My package is currently setup improperly for demo purposes on an issue over at ts-node. By having export * from './models' on core, it is allowing for the web package to use the source even though it isn't listed as a dependency (this is for a fullstack mono so that's a problem).

tsconfig-paths works, I just have my concerns over using it beyond dev though.

Thank you for the awesome article btw. It really helped me better understand the structuring.

from ts-monorepo.

I fixed it with the projectReferences option on ts-loader

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin')

module.exports = {
  entry: './src/index.ts',
  mode: 'development',
  output: {
    filename: 'bundle.js',
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js'],
    plugins: [new TsconfigPathsPlugin()],
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        loader: 'ts-loader',
        options: { projectReferences: true },
      },
    ],
  },
}

from ts-monorepo.

Having said that, I still think using references is the way to go though. It eliminates the need for the build files and makes the build process faster.

From the docs:

you’ll either have to check in certain build outputs or build a project after cloning it before you can navigate the project in an editor without seeing spurious errors

Path aliases provide a better out of the box experience for code navigation. The speed improvements you could get from project references will only be possible when you cache build artifacts, cold builds (usually the case in a CI env) should not see any benefits.

I fixed it with the projectReferences option on ts-loader

I'm glad you found a fix! I wasn't aware of that option, nor am I aware of other webpack loaders that support it. I think project references have a bit to go before they become a viable all-in-one solution due to the caveats mentioned in the docs and the lack of support in the tooling ecosystem.

from ts-monorepo.

Path aliases provide a better out of the box experience for code navigation.

So references just kick off the build but you still need path aliases. They also get around the fact that the files are outside of the rootDir.

You can see it here: https://github.com/chanced/ts-monorepo

from ts-monorepo.