feat: TsImportType - support import attributes #9796
Conversation
|
| @@ -546,6 +546,8 @@ pub struct TsImportType { | |||
| pub qualifier: Option<TsEntityName>, | |||
| #[cfg_attr(feature = "serde-impl", serde(rename = "typeArguments"))] | |||
| pub type_args: Option<Box<TsTypeParamInstantiation>>, | |||
| #[cfg_attr(feature = "serde-impl", serde(default))] | |||
| pub with: Option<Box<ObjectLit>>, | |||
There was a problem hiding this comment.
I'm not sure about this name because this is the full { with: { "module-resolution": "import" } } (which I need for dprint-plugin-typescript). Maybe something else would be better here?
There was a problem hiding this comment.
I'll wait to update the failing tests until getting feedback on this.
There was a problem hiding this comment.
So annotation? I think we may need to use separate type for this kind of annotations. How do you think? cc @swc-project/core-es
There was a problem hiding this comment.
Is with hardcoded?
I hope there is no situation like { with: { "foo": "bar" }, other: "value" }.
There was a problem hiding this comment.
From https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-3.html
The expected type of that second argument is defined by a type called
ImportCallOptions, which by default just expects a property calledwith.
And typescript playground throws Object literal may only specify known properties, and 'xxx' does not exist in type 'ImportCallOptions'.
So I think some names related to ImportCallOptions or just attributes are ok as well.
There was a problem hiding this comment.
I think we need a breaking change anyway if there's a situation like { with: { "foo": "bar" }, other: "value" }, and I like the idea of
ImportCallOptions or just attributes
There was a problem hiding this comment.
I updated to this (I think)
| @@ -316,6 +316,18 @@ impl<I: Tokens> Parser<I> { | |||
| } | |||
| }; | |||
|
|
|||
| // the "assert" keyword is deprecated and this syntax is niche, so | |||
| // don't support it | |||
There was a problem hiding this comment.
I don't think we should support the "assert" keyword for these reasons.
There was a problem hiding this comment.
This file was difficult to figure out how to run (cargo run --package generate-code -- --input-dir crates/swc_ecma_ast --output crates/swc_ecma_visit/src/generated.rs). It might be good to add instructions somewhere.
Also, running that command generates a bunch of other things that I reverted because they were unrelated to this PR. I think maybe this file is out of date on main. It might be good to add some CI verification to ensure it stays up to date.
There was a problem hiding this comment.
I know this is not intuitive, but you can run UPDATE=1 cargo test from tools/generate-code.
I think we should add an alias for this and document it.
CodSpeed Performance ReportMerging #9796 will degrade performances by 4.25%Comparing Summary
Benchmarks breakdown
|
|
Could someone re-run the test expectations for me if the changes look good? I had so much trouble getting yarn 4 running on my machine and gave up. |
|
I’ll do it later today |
Description:
This parses, emits, and visits import attributes in TsImportType.
BREAKING CHANGE:
Adds an additional property to
TsImportTypeRelated issue (if exists): #9377