document.createElement is converted to JSX

[milahu]

Describe the bug

jsx is not javascript

with input.js i expect javascript in output.js

with input.jsx jsx output can be acceptable in output.jsx

Input code

const Name = "div";
const attrs = {id: "x"};
document.createElement(Name, attrs);

Reproduction

No response

Steps to reproduce

No response

Expected behavior

keep document.createElement

Actual behavior

const Name = "div";
const attrs = { id: "x" };
<Name {...attrs} />;

$ node out/test.js
out/test.js:3
<Name {...attrs} />;
^

SyntaxError: Unexpected token '<'

also the JSX is wrong, JSX has no dynamic tag names (?)
so it should be <div {...attrs} />

[pionxzh]

Rule un-jsx will guess JSX API by searching *.createElement without checking if the caller is document. I will fix it by excluding document. But it will still fail in the following case:

const d = document;
d.createElement(...)

I would like to introduce another rule to inline temp variables which were assigned to common global variables. For example:

- const w = window;
- w.setTimeout(...);
+ window.setTimeout(...);

I hope this can improve the readability and avoid misunderstanding the intention of the code.

[milahu]

aah, i was looking for

https://github.com/pionxzh/wakaru/blob/main/packages/unminify/README.md#un-jsx

... but i dont see a way to disable rules

[pionxzh]

You can disable it on the playground. CLI has not supported configuring the rules yet.

If you are running this repo in local environment, simply disable it in file packages/unminify/src/transformations/index.ts

[pionxzh]

JSX has no dynamic tag names (?)

This is a supported use case in JSX.

But your proposal is an improvement that we can make. I'm not sure if it's a common case that bundler/minifier will generate.

[pionxzh]

Fixed

[pionxzh]

I have created another feature request for the tag name in #115

[milahu]

similar case

wrong transformation from h(...) to JSX

wakaru assumes that h is the h function of hyperscript

to get this right, wakaru would have to check the actual implementation of the h function

input

let h = (w, x, z) => w.split(x).join(z);
let b = (w) => {
  w = w.toLowerCase();
  w = h(w, " ", "");
  w = h(w, "-", "");
  let x = "400";
  if ((w = h(w, "_", "")).includes("thin") || w.includes("hairline")) {
    x = "100";

output

let h = (w, x, z) => w.split(x).join(z);
let b = (W) => {
  W = W.toLowerCase();
  W = <W {..." "}>{""}</W>;
  W = <W {..."-"}>{""}</W>;
  let x = "400";
  if ((W = <W {..."_"}>{""}</W>).includes("thin") || W.includes("hairline")) {
    x = "100";

[pionxzh]

hmm ye, h would be too common to hit on non-jsx code.

[pionxzh]

We also have the plan to do the module detection. Ideally, we should be able to detect which module is react/preact and convert the call to JSX precisely.

[pionxzh]

preact's h pragma is disabled until we implement the module detection.

[pionxzh]

released

[pionxzh]

I would like to introduce another rule to inline temp variables which were assigned to common global variables. For example:

- const w = window;
- w.setTimeout(...);
+ window.setTimeout(...);

This has been added in 1a91aa4