-
Notifications
You must be signed in to change notification settings - Fork 115
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
Make #[ts(export_to = "...")]
relative to TS_RS_EXPORT_DIR
#250
Conversation
This is so annoying, docs.rs passes on my computer, but not on ci |
That's weird, changing the order of the tests changed which one failed |
I don't quite understand what's going on, but it seems like in |
Running |
macros/src/lib.rs
Outdated
let export = self | ||
.export | ||
.then(|| self.generate_export_test(&rust_ty, &generics)); | ||
|
||
let export_dir = std::env::var("TS_RS_EXPORT_DIR").ok(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, I think this here might be the issue!
This is evaluated when the macro executes, during compilation.
When later running this executable, the TS_RS_EXPORT_DIR
is hard-coded in there.
That might also happen when just doing cargo test
, since rust might not re-compile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're right, I just commited a version using std::option_env!
instead and that seems to have fixed it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still, it might be better to move reading the env variable to export.rs
instead, because I think the way I just did it forces recompilation, which kinda sucks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, both with the observation as well as the conclusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The last change did cause a recompilation, but recompilation of ts-rs-macros
.
The 3 possible behaviours we could get are
- Re-compile ts-rs-macros (which also re-compiles the consumer crate)
Useenv!
ints-rs-macros
- Re-compile the consumer crate
Load the environment variable inexport.rs
, usingenv!()
- Don't recompile anything
Load the environment variable inexport.rs
, usingenv::var()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it fixed! Sorry about the billion failed CI notifications 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Don't recompile anything
Load the environment variable inexport.rs
, usingenv::var()
Ended up on this one, my cpu is already thanking me 😆
I finished moving |
I could add a method that returns the proper path to remedy this |
let base = std::env::var("TS_RS_EXPORT_DIR") | ||
.ok() | ||
.as_deref() | ||
.map(Path::new) | ||
.unwrap_or_else(|| Path::new(".")) | ||
.to_owned(); | ||
let export_to = | ||
T::get_export_to().ok_or(ExportError::CannotBeExported(std::any::type_name::<T>()))?; | ||
let path = Path::new(&export_to); | ||
T::EXPORT_TO.ok_or(ExportError::CannotBeExported(std::any::type_name::<T>()))?; | ||
let path = base.join(export_to); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we re-use output_path
here? Might be the case that we have to get rid of the path::absolute
in output_path
for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't even think we need to remove path::absolute
, this path will be fed into diff_paths
, which uses absolute paths as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, perfect!
The reason I was thinking about adding it to |
ts-rs/src/lib.rs
Outdated
let base = std::env::var("TS_RS_EXPORT_DIR") | ||
.ok() | ||
.as_deref() | ||
.map(Path::new) | ||
.unwrap_or_else(|| Path::new(".")) | ||
.to_owned(); | ||
|
||
let exported_to = base | ||
.join(T::EXPORT_TO.map(ToOwned::to_owned)?) | ||
.to_string_lossy() | ||
.to_string(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing here, might be nice to re-use output_path
here as well
Yeah, that's a good point. If you think it makes sense, go for it! |
I agree that the function that returns the path should never be overwritten. Maybe a Making |
* document `#[ts(tag)]` and `#[ts(as)]`, reformat documentation * fix line breaks in README.md * put cargo features in a table * Fix typo in readme * Document change to export_to made in #250 * Add missing newline * Explain flatten * Document #[ts(untagged)] on enum variants * Document #[ts(rename_all = ..)] on enum variants * Add missing newline * Change interface to type * Link to mentioned items * Run cargo readme * Document TS::DOCS * Improve TS::ident so it doesn't panic * document TypeList --------- Co-authored-by: Gustavo <[email protected]>
As discussed in #245, when using both
TS_RS_EXPORT_DIR
and#[ts(export_to = "...")]
, theexport_to
path should be relative toTS_RS_EXPORT_DIR
instead of the project'sCargo.toml