共享的React前端组件->使用TypeScript的单独项目-> Visual Studio 2017

Question

We have the following project structure in Visual Studio. The reason we have a SharedComponents project is because a lot of components are shared between our client and admin interface. We use the feature pattern and would like to have this project structure.

/src(.sln)
--/PublicClient
--/Admin
--/SharedComponents

Our SharedComponents project is not a Visual Studio Shared Project but a Class Library because we use TypeLite NuGet to generate TypeScript interfaces from .NET classes.

We are facing a lot of problems due to the fact that the SharedComponents project has its own package.json , tsconfig.json and tslint.json .

Module agumentation is one of the problems described here:

Typescript 2.6 -> Extend type definition for external library with module augmentation -> TS2339: Property '' does not exist on type ''

One feature that we do not wan't to loose is hot reloading with webpack-dev-server if we change anything in either of the projects, including SharedComponents.

I have read a lot of threads about this but not found any good solution.

npm link causes build errors due to dependencies in node_modules being moved.

https://github.com/npm/npm/issues/10343

https://github.com/facebookincubator/create-react-app/issues/1492

We do not want to skip the shared project and copy the files to both our projects. It would be to time consuming to maintain the same components in two different projects.

If we open source our shared project to NPM or use another service like NPM private modules , linklocal , Bit or sinopia we will loose hot reloading and/or have to maintain the package separately.

Has anyone else been in the same situation and found a good solution?

Answer 1

We decided to put all our front end code in one project and then use separate folders there. This means we only have one package.json , node_modules , tsconfig.json and tslint.json . We can't have the API:s in the same project but since we can use hot reloading with webpack-dev-server it was still a good trade off in the end.

We then used two separate webpack.config.js files called webpack.publicclient.config.js and webpack.admin.config.js for different configurations.