Skip to content
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

Import assertions are blanket converted to import attributes #7908

Closed
PaulSinghDev opened this issue Sep 1, 2023 · 6 comments · Fixed by #7914
Closed

Import assertions are blanket converted to import attributes #7908

PaulSinghDev opened this issue Sep 1, 2023 · 6 comments · Fixed by #7914
Assignees
Milestone

Comments

@PaulSinghDev
Copy link

PaulSinghDev commented Sep 1, 2023

Describe the bug

When using the jsc.experiment.keepImportAssertions flag the SWC compiler simply takes all assertions and outputs the new with { type: "some-type" } syntax regardless of what the input was.

This causes issues with Node being able to run the code and generates a syntax error when trying to run the generated code. As it has been accepted that the assert syntax will not be getting removed there is no need to blanket change the syntax as this causes more issues than it solves.

Input code

import packageJSON from "./package.json" assert { type: "json" };

Config

{
  "$schema": "https://json.schemastore.org/swcrc",
  "jsc": {
    "parser": {
      "syntax": "typescript"
    },
    "target": "es2022",
    "experimental": { "keepImportAssertions": true }
  },
  "module": {
    "type": "es6"
  },
  "isModule": true
}

Playground link

https://play.swc.rs/?version=1.3.82&code=H4sIAAAAAAAAA8vMLcgvKlEoSEzOTkxP9Qr291NIK8rPVVDS04eK6WUV5%2BcpKSQWF6cCFVaXVBakWikogQVrrbmS8%2FOK83NS9XLy0zWQDNG0BgDW5p%2FHWQAAAA%3D%3D&config=H4sIAAAAAAAAA0VOOw7CMAzdc4rIMwPKwMDGyMAhomKhQNNYtiu1qnL3OrSUze%2FvxXkPb%2Bng6hc7DVBkQT6wMTIPGidjQGdC6TiRwlespy2jkV%2BozYESziHAzuNEyCmj5fvW6OGDSPdMhfUmNqOpDGKK8oi%2Bur0RcnmOPf5%2Fartb%2BwUOU5LHz9birroVVF6is80AAAA%3D

SWC Info output

No response

Expected behavior

The type of assertion is preserved.

Actual behavior

The assertion is transformed into the newer with syntax.

Version

1.3.82

Additional context

I have solved this issue for me by downgrading to swc version 1.3.80. However, I think a more flexible solution is required.

@kdy1
Copy link
Member

kdy1 commented Sep 1, 2023

The option should be removed or renamed, I think, but this is not a bug.

@kdy1 kdy1 removed the C-bug label Sep 1, 2023
@PaulSinghDev
Copy link
Author

Sorry @kdy1 I wasn't sure what to label it as. I just went for bug as it was causing me issues.

I figure it shouldn't be too much of a challenge to check whether the dev used assert or with and then just output the same as the input.

I have tried changing the target version but it seems as though the compiler just wants to always output code with with

@kdy1
Copy link
Member

kdy1 commented Sep 1, 2023

@kwonoj @alexander-akait @magic-akari @Austaras
What's your opinion about this option? This can't be implemented as a Wasm plugin because codegen will always use with, so if we decide to support emitting asserts, it should be done in @swc/core

@magic-akari
Copy link
Member

pub struct ImportDecl {
pub span: Span,
#[cfg_attr(feature = "serde-impl", serde(default))]
pub specifiers: Vec<ImportSpecifier>,
#[cfg_attr(feature = "serde-impl", serde(rename = "source"))]
pub src: Box<Str>,
#[cfg_attr(feature = "serde-impl", serde(default, rename = "typeOnly"))]
pub type_only: bool,
#[cfg_attr(feature = "serde-impl", serde(default))]
pub with: Option<Box<ObjectLit>>,
}

During the process of parsing code into an AST, we lose the information required to differentiate whether it represents a "with" statement or an "assert" statement.
The transformation can still be implemented in the WASM plugin, but it require the addition of extra information to the AST.

There are two potential solutions:

  1. Modify the AST to record the current with/assert variant.
  2. Assume that the coexistence of both variants is not possible and generate the expected code during code generation based on the selected option.

@Austaras
Copy link
Member

Austaras commented Sep 1, 2023

Seems to me that adding an option to codegen would be the most logical solution.

@kdy1 kdy1 added this to the Planned milestone Sep 1, 2023
@kdy1 kdy1 self-assigned this Sep 1, 2023
@kdy1 kdy1 closed this as completed in #7914 Sep 5, 2023
kdy1 added a commit that referenced this issue Sep 5, 2023
…es (#7914)

**Description:**

- `jsc.experimental.keepImportAssertions` is renamed to `jsc.experimental.keepImportAttributes`.
 - `jsc.experimental.emitAssertForImportAttributes` is added.

**Related issue:**

 - Closes #7908
@kdy1 kdy1 modified the milestones: Planned, v1.3.83 Sep 7, 2023
@swc-bot
Copy link
Collaborator

swc-bot commented Oct 7, 2023

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@swc-project swc-project locked as resolved and limited conversation to collaborators Oct 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging a pull request may close this issue.

5 participants