Adding local TypeScript dependency does not work

[JollyGoodHolly]

I'm not sure whether this is a genuine bug or I just missed something in the documentation, hence I'm posting here.

I have two CRA TypeScript projects: one app ("webapp") and one library ("webapp-commons") with utils and some APIs that the app should use. This is that I could write second app that uses the same utils without cop-pasting them, and hence I have this structure:

root/
├── webapp/
│   ├── src/
│   ├── package.json
│   └── ...
└── webapp-commons/
    ├── src/ ...
    ├── package.json
    └── ...

To include webapp-commons as a dependency, the package.json of webapp includes this line:

"dependencies": {
...
  "webapp-commons": "file:../webapp-commons",
...
},

Accordingly, NPM creates a symlink in the node_modules folder that links to webapp-commons. I can now use the components of webapp-commons in webapp. IntelliJ has no problem resolving the dependency. However, when I try to start or build the app, I get the following error:

Module parse failed: The keyword 'interface' is reserved (15:0)
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 { BrowserRouter, Route, Switch } from "react-router-dom";
|
> interface CommonsAppProps {
|     component?: React.ComponentType<RouteComponentProps<any>> | React.ComponentType<any>;
| }

This is despite the code clearly being valid and the file compiling just fine independently (via tsc) or when copied to webapp. The error suggests that ts/tsx files are not configured in whatever build step is executed here. I tried ejecting webapp and fiddling with the webpack.config.js but so far had no luck, and I have no expertise with Webpack either.

Therefore I have these questions:

1. Is this a bug that could be fixed within CRA/react-scripts?
2. If not, is there a plausible workaround? Possibilities that spring to mind are config injection (via rewire), and transpiling the webapp-commons every time and linking the JS files. However, I wouldn't know how to do either properly.

I would like to avoid ejecting the webapp, as I would have to do so for every new webapp I create. Publishing to NPM is not an option due to this being a corporate project; I cannot share exhaustive code snippets for the same reason.

[JollyGoodHolly]

I was able to create a workaround for this issue using timarney/react-app-rewired and the oklas/react-app-rewire-alias extension. There was a caveat for TypeScript projects domiciled outside the root project's directory, pertaining to CRA's ESLint configuration, which I was able to fix myself, see my comment on oklas/react-app-rewire-alias#3.

I'd still love to see whether there is a proper, native implementation for this in CRA, as I'm sure that I'm not the only one with such a setup.

[eddiemonge]

Seems related to #9040

Does your webapp-commons have a build step? It sounds like you are trying to load the module source instead of the built files. Try building the commons first and then see if its the same thing

[JollyGoodHolly]

@eddiemonge I do not have a build process configured for my commons, which contains only plain TS/TSX source files. The expected behaviour, which my above workaround produces, is that they are indexed as project source files and compiled along with the rest, even triggering re-compiles of the dev server. Maybe CRA should allow aliased imports to fix this natively.

[eddiemonge]

This seems more like an edge case. You are basically asking the system to manage and build an external dependency as if it was your source. Even though you do control it and it is local, you have to remember that it is still "external".

If you really want to it to be more included, do an actual symlink in the src folder instead of npms symlink in the node_modules folder.

If you do really want it to be a sibling project, meaning its fully external, run its cra build at the same time as the one webapp so you have two instances running.

[JollyGoodHolly]

Is it really "external" when configured as an aliased import in the tsconfig.json? This would be a mere path mapping, not a dependency.

[eddiemonge]

That is different than what you described. You said you added it as a dependency in package.json

[JollyGoodHolly]

Since the workaround, the dependency is no longer required. I'll open a new ticket.