-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Combine exports into single file #59
Comments
I would like to support this, but I'd just like to not that this is not an easy feature to implement properly. In earlier versions, there was a So I'm open to the idea, but we'll have to figure out how to do the neccessary coordination between the invocations of |
@NyxCode I propose that perhaps we can add a |
@thorlucas I was thinking of something different: |
I took a quick look at this, because I'd like to have this feature, too.
There was a recent blog entry IDEs and Macros describing the challenges for code-analyzers with non-
The order in which tests are run is unspecified. We cannot create a test that is guaranteed to run after all others. We could let each test add their info to a Or, as you said, we write it to disk and run a bundler in a post-processing step, after Yet another idea is to embrace the files, but re-export everything in an for f in bindings/*.ts ; do echo "export * from './$f';" ; done > index.ts |
@cauthmann I think you misunderstood what I was saying - We could write the files in the proc macro, then have a test read those files. The test will definetely run after all proc macros are expanded. |
I found a bit of a workaround to do this that allows creation of a static str in the main crate with the TS definitions. This is useful for wasm bindgen as we can use a #61 TS custom section to output the TS directly to the wasm bindgen created .d.ts file. But it involves using a second proc macro crate to loop through all tagged types and combine their ::decl()s into one string. Perhaps the ts-rs could do something like this? (apologies for formatting im on mobile) |
Hm, didn't think about this before, but the issue we run into with this is that after removing a |
Wasn't the point of the testcases that we don't have all the info inside the proc macro, like the full paths of identifiers? What information could we write to disk in a proc_macro that's useful later? Another approach I found via an unrelated reddit discussion is linkme. It's certainly dark magic, and less portable than abusing tests, but it would allow us to catch all types from a crate and process them together. I played around with it, and it seems to work. There's still feature-gates and a long command line to generate the bindings, but I can run a function which has access to the info from ALL types contained in the crate. in ts_rs: #[linkme::distributed_slice]
pub static TYPEINFO: [fn() -> (PathBuf, String)] = [..];
pub fn export_bindings() {
println!("Got {} types", TYPEINFO.len());
for f in TYPEINFO {
let (path, code) = f();
println!("Got a type: {}\n{}", path.display(), code);
}
} Calling
In a production solution, the typeinfo would return something akin to |
Second that this feature would be great. Is the current status that there's still no good way to do this, and folks aren't interested in a hacky solution of having a test bundle up all the written files? |
Having an |
From my understanding, this feature needs an API break to be implemented in a non hacky way. The current API, due to how the trait I would have an API of the form: trait TSDef: Clone {
fn type_id(&self) -> u64; //for checking if two TSDef are equal, maybe a better way might be the use of PartialEq
fn name(&self) -> String;
fn decl(&self) -> String;
fn dependencies(&self) -> Vec<Box<dyn TSDef>>;
}
trait TS {
type Def: TSDef;
fn get_type_def() -> Self::Def;
} Having an instantiable object representing a typescript type allows the construction of the entire dependency graph from a single |
@Andful I just came back to this issue, over a year later, and we ended up with something similar-ish. On the current master, we use this to automatically export all dependencies, though still into separate files. The main motivation behind this change was the scenario where your types contain types from a library which implement/derive |
I still believe that, at least by default, exporting one file per type is the right choice. Exporting into a minimal number of files while not duplicating types would only be possible if the user specifically mentioned the types in one place. With just However, generating an index file which re-exports all types seems like low-hanging fruit. At some point, we'd like to introduce a CLI tool, which would be the perfect place to do that. |
I think that any exports within the same module should be combined into a single file, rather than splitting them up into separate files. I feel as though this should be the default, but perhaps a directive at the top of the module could indicate whether or not this happens?
The text was updated successfully, but these errors were encountered: