Generator fails to use type from library

[SmallhillCZ]

Tried to use controller, which returns some data directly from stripe library but nest-sdk-generator fails with:

ERROR: File stripe was not found (was expected to contain dependency type Stripe)

[SmallhillCZ]

Or is this because of the namespace?

Could there be at least some hard overwrite, something like the magicTypes, but which would not check if the file exists, just replace the type and not fail?

[clement-estone]

What do you mean exactly? The type cannot be imported as the stripe package doesn't exist client-side.

[SmallhillCZ]

Sorry, probably didnt explain it correctly. Also might be that I'm not understanding some part correctly, namely the README.md#L198.

In my case the stripe package actually does exist on both the server-side and the client-side, but the actual problem for me is that the generation of sdk on the server-side fails on the error that <root>/stripe is not found (at src/analyzer/extractor.ts#L209) and therefore I have no way of solving it other way (e.g. using magicTypes)

So I would need either:

1. that the nest-sdk-generator actually finds the stripe package in node_modules/stripe on server-side and copies all needed type definitions to the _types/node_modules/stripe/... (as is shown in README.md#L198)
2. or that I directly specify a rule that says "when the import path is stripe, the client library should use the local package stripe"

The latter is the same (similar) as done in the magicTypes, where I could import the local package in the placeholderContent, but magicTypes is not applicable for me because nest-sdk-generator fails before it is applied.

---

Referenced code snippets:

nest-sdk-generator/src/analyzer/extractor.ts

Lines 207 to 211 in 5b5637d

	if (!fileAndPath) {
	return new Error(
	format('File {magenta} was not found (was expected to contain dependency type {yellow})', loc.relativePathNoExt, loc.typename)
	)
	}

nest-sdk-generator/README.md

Lines 189 to 199 in 5b5637d

	#### Importing API types
	It's also possible to manually import types the API depends on.
	For instance, let's suppose `UserDTO` comes from a shared DTO package which is installed in our NestJS API's directory under `node_modules/@project/dtos/user.d.ts`.
	We can import it from the SDK like this:
	```typescript
	import { UserDTO } from '<sdk path>/_types/node_modules/@project/dtos/user.d'
	```

[clement-estone]

Thanks for the explanation.

Auto-extracting the types required from the namespace is actually really hard, which is why it isn't available as a feature in the SDK generator. The way namespaces work in the TypeScript compiler is really hard makes them really hard to use.

The package replacement solution would be interesting though, but it requires the exact same package to be present on the client and server side - is that your case?

[SmallhillCZ]

Yes, in my case it is exactly the same package. It could also work for cases when type definition packages are being shared among frontend/backend for other use cases than only direct API interaction and don't need to be included.

Basically it would be just saying to the nest-sdk-generator that this package is "peer dependency" of the SDK and the types will not be included in the output and it is up to the user of the sdk to include it.

[SmallhillCZ]

Btw, I was looking at other solutions (I like your's because of the approach with using custom request function allowing to include it more seamlessly to the client project¹) and some of them generate a full npm package including package.json (which I also like²), where the peerDependency could be explicitly specified.

¹ I can expect same response type (Observable/Promise and structure) as the HTTP library used elsewhere in the app
² the generated SDK can be shared easily among other projects and repos

[SmallhillCZ]

I have created a little proof of concept repo with the suggested changes:

• PoC repo: https://github.com/SmallhillCZ/nest-sdk-generator-stripe-problem
• suggested changes (tried to stick to your conventions, but...) SmallhillCZ@180f4d6

[clement-estone]

Thanks for your contribution ; I don't think it would be a good idea to generate a package.json though as it's outside the scope of a simple SDK generator. Also, peer dependencies are often a footgun in a good number of scenarios, especially since they are absolutely required here.

You can also have a different version requirement between the client and the server (e.g. you don't update the server for whatever reason but need to update the client, or vice-versa).

I think it would be more relevant to just add an option to specify that some packages should be imported from the same package client-side instead of extracting it.