Workspace watch mode does not update Typescript definitions

Question

Workspace watch mode does not update Typescript definitions

Greetings to all who are reading this,

I have created a React micro-frontend project using SPA v5.9, Webpack v5.75, Babel-loader v9.1, Ts-loader v9.4, and Yarn workspace v3.5. The project structure is very basic:

Root SPA => Package Root
Application SPA => Package App1
Utils SPA => Package Utils1
React lib Utils SPA => Package Utils2

My current challenge arises when running the app on Webpack dev server. If I add a new function to Utils1 and try to use it in App1, TypeScript throws an error stating that there is no existing export for this function.

The application runs without issues, so I suspect it's a misconfiguration of either Webpack, loaders, or TypeScript settings. Unfortunately, I am not well-versed in this specific setup and haven't been able to find a solution on Stack Overflow or GitHub repositories.

To see more details about the configuration used, you can visit my project here.

My main question is: How can I resolve the TypeScript error occurring when using Webpack?

I believe that sharing the solution from my repository could benefit others who are facing similar challenges in structuring their projects. So, it would be great to find and share a resolution :)

An interesting observation is that the updated d.ts files of Utils1 are successfully created in my dist directory by Ts-loader and emitted in App1 as assets by path ../../utils1. However, this seems insufficient.

Here are some logs from the console when adding a new function:

...

And here is the error log when trying to utilize that function:

...

typescript webpack single-page-application micro-frontend yarn-workspaces

Answer 1

Answer №1

Today, I utilized my brain wisely and successfully configured webpack to run smoothly.

I suspected that the configuration issue stemmed from the fork-ts-checker-webpack-plugin embedded by webpack-config-single-spa-ts v4.1.3. Upon further inspection of its configuration, I discovered that it did not align with the documentation provided.

          new ForkTsCheckerWebpackPlugin({
            typescript: {
              mode: "write-references",
            },
          }),

According to the fork-ts-checker-webpack-plugin documentation, when using

mode: "write-references"

, we also need to set build: true. After some research, I realized that enabling the build mode of tsc would compile our reference project unnecessarily. I updated the configuration as follows:

      new ForkTsCheckerWebpackPlugin({
        typescript: {
          mode: "readonly",
          build: true,
        },
      }),

This adjustment met my expectations and worked seamlessly during development under webpack:

If I modify a method in the utils1 project used by app1, it will generate a valid typescript error :)
If I add a function to utils1 and call it from app1, there are no complaints about unknown exports from utils1 :)

This configuration only affects packages that use references in tsconfig, excluding the root app and utils in my case.

I also optimized the configuration for my spa utils by keeping it empty to default as my utils do not depend on other packages. This results in in-memory files:

new ForkTsCheckerWebpackPlugin({}), // Overrides the conf mode: "write-references" from singleSpaDefaults. We use in-memory readonly definition, assuming you run your production build with tsc.

All these modifications can be found in the develop branch of my repository.

In the upcoming commits, I plan to add fast-refresh and CSS prefixing by package, along with other features. Feel free to engage in discussions or raise issues if you have suggestions for enhancing the repository :)

Initial investigation findings:

I believe I have narrowed down the source of the error messages originating from the fork-ts-checker-webpack-plugin plugin. Removing it from the webpack configuration in the app1 webpack conf has resolved the errors.

I pursued this approach because the fork-ts-checker-webpack-plugin operates in a separate process, potentially causing asynchronous issues with webpack.

However, I am uncertain whether by removing it:

I have completely disabled TypeScript checking

Or simply shifted the responsibility of type checking solely to the ts-loader.

What is your perspective on this?

I intend to explore any potential side effects further.

Find the update in this branch of my repository

Answer 2

Today, I utilized my brain wisely and successfully configured webpack to run smoothly.

I suspected that the configuration issue stemmed from the fork-ts-checker-webpack-plugin embedded by webpack-config-single-spa-ts v4.1.3. Upon further inspection of its configuration, I discovered that it did not align with the documentation provided.

          new ForkTsCheckerWebpackPlugin({
            typescript: {
              mode: "write-references",
            },
          }),

According to the fork-ts-checker-webpack-plugin documentation, when using

mode: "write-references"

, we also need to set build: true. After some research, I realized that enabling the build mode of tsc would compile our reference project unnecessarily. I updated the configuration as follows:

      new ForkTsCheckerWebpackPlugin({
        typescript: {
          mode: "readonly",
          build: true,
        },
      }),

This adjustment met my expectations and worked seamlessly during development under webpack:

If I modify a method in the utils1 project used by app1, it will generate a valid typescript error :)
If I add a function to utils1 and call it from app1, there are no complaints about unknown exports from utils1 :)

This configuration only affects packages that use references in tsconfig, excluding the root app and utils in my case.

I also optimized the configuration for my spa utils by keeping it empty to default as my utils do not depend on other packages. This results in in-memory files:

new ForkTsCheckerWebpackPlugin({}), // Overrides the conf mode: "write-references" from singleSpaDefaults. We use in-memory readonly definition, assuming you run your production build with tsc.

All these modifications can be found in the develop branch of my repository.

In the upcoming commits, I plan to add fast-refresh and CSS prefixing by package, along with other features. Feel free to engage in discussions or raise issues if you have suggestions for enhancing the repository :)

Initial investigation findings:

I believe I have narrowed down the source of the error messages originating from the fork-ts-checker-webpack-plugin plugin. Removing it from the webpack configuration in the app1 webpack conf has resolved the errors.

I pursued this approach because the fork-ts-checker-webpack-plugin operates in a separate process, potentially causing asynchronous issues with webpack.

However, I am uncertain whether by removing it:

I have completely disabled TypeScript checking

Or simply shifted the responsibility of type checking solely to the ts-loader.

What is your perspective on this?

I intend to explore any potential side effects further.

Find the update in this branch of my repository

Workspace watch mode does not update Typescript definitions

Answer №1

Similar questions

Conflicting TypeScript enum types: numbers and numbers in NestJS/ExpressJS

Reactjs Promise left hanging in limbo

Using React hooks and Typescript: I was expecting to see an assignment or function call, but instead, an expression was

Issue with Dates in Typescript array elements

What is the best way to iterate over an Angular HTTP Response?

Every time I clear the information, it seems to be instantly replaced with new data. How can I prevent it from constantly refilling?

Is there a way to set a default value for an Angular service provider?

Binding an ID to an <ion-textarea> in Ionic 3

"Launching" conduit for Observable

Differences between ts-loader and babel-loader when working with TypeScript in webpack

The selected image should change its border color, while clicking on another image within the same div should deselect the previous image

Do you believe this problem with transpilation has been properly reported to babel-jest?

Best practices for transferring date objects between a frontend developed in JavaScript/TypeScript and a backend built in ASP.net Core 5

Using RxJS to merge various HTTP requests into a unified and flattened observable array

Adjusting the timing of a scheduled meeting

Using Webpack 4 and React Router, when trying to navigate to a sub path,

What could be causing the inability to update a newly logged-in user without refreshing the page?

Leverage the new Animation support in RC 5 to animate each item in an *ngFor list sequentially in Angular 2

Retrieve the Document ID from Firebase

Guide on mocking a function inside another function imported from a module with TypeScript and Jest