Replies: 1 comment 2 replies
-
Hi Salman! The reason As a result, this library works out of the box with Vite Ruby, even when I usually prefer absolute imports in manually written code—such as However, for generated code it should be fine to use relative imports, as it's a better way to ensure it works out of the box if I'd accept a pull request that uses relative imports, but it's not as simple as replacing the default with It will be necessary to resolve the path of the target serializer against the path of the current serializer file to ensure it works as expected for all cases (namespaced serializer uses non-namespaced serializer vs same-namespace vs different namespace). |
Beta Was this translation helpful? Give feedback.
-
Hi there!
Thanks for building this library. I'm working on using it to generate Typescript types from our Rails app to be used in our (currently separate) React app. For now, we have the generated type folder in Rails (
frontend/types/*
) symlinked inside the React app.When we do this, we run into an issue with the files due to the path prefix on import statements. So if you have a type A that includes an attribute of another type B, it will have a generated import statement at the top, it will have an import statement for the other type that looks like this:
import type B from '~/types/serializers/B'
This causes an error
Cannot find module '~/types/serializers/B'
, which we discovered is due to the relative path it uses (i.e. the~/
bit.I'm curious why the path is generated with a
~
instead of./
? What we would expect is for the import path to match the way it's done in the generatedindex.ts
file, like so:export type { default as B } from './B'
In other words, using
./
instead of~/types/serializers
.Right now, it is hard-coded to that path: https://github.com/ElMassimo/types_from_serializers/blob/main/types_from_serializers/lib/types_from_serializers/generator.rb#L112
To address this use case (and I imagine others who use this lib), it would be helpful to take a configuration option for the import path prefix. I was thinking of potentially forking this and putting up a PR to add support for the configurable path. But before I did that, I wanted to ask A) the thinking behind current value, B) if configurability would be a useful PR, and/or C) if changing the default value to
./
would still work for your primary use case as well.Thanks!
Beta Was this translation helpful? Give feedback.
All reactions