feat(ci): remove need to compile scripts

[christian-bromann]

What is the current behavior?

Currently a developer working on Stencil needs to compile the entire scripts folder first before running the files in them. This seems cumbersome and there is an opportunity to improve the DX here.

What is the new behavior?

By adding tsx we can get rid of the intermediate build step by running TS files on demand. This simplifies a lot of internal scripts and confusion when it comes to resolving paths.

Documentation

Does this introduce a breaking change?

• Yes
• No

Testing

Checkout the branch and run npm run build.

Other information

n/a

[github-actions]

PR built and packed!

Download the tarball here: https://github.com/ionic-team/stencil/actions/runs/9270562098/artifacts/1544405233

If your browser saves files to ~/Downloads you can install it like so:

unzip -d ~/Downloads ~/Downloads/stencil-core-4.18.2-dev.1716904125.f0e8bf4.tgz.zip && npm install ~/Downloads/stencil-core-4.18.2-dev.1716904125.f0e8bf4.tgz

[christian-bromann]

Tech Debt Burndown / Download error files and report (pull_request_target) Failing after 31s

This is due to the fact that we are running the workflow from main which still uses the compiled script.

[christian-bromann]

@tanner-reits @alicewriteswrongs this is ready for review now.

[tanner-reits]

Any reasoning on choosing tsx over ts-node? Just curious.

[christian-bromann]

tsx is much better maintained as ts-node. I am switching in all my projects to tsx now.

[alicewriteswrongs]

Definitely a nicer DX here! It's a bit less mysterious why we're doing what we doing for the build here I think.

One thing I'm wondering about is type checking for the scripts/ directory. In our current setup on main we run a full typescript build of the directory which means that we'll never end up running the scripts if there's a type error. From what I can tell tsx takes the stance as a project that type checking in e.g. your editor is good enough and does not do any type checking when you go to execute a file (I confirmed that by putting const stringy: string = 1; into scripts/index.ts and I was able to run it with no error).

Anywhooo - just wondering if this is the direction we want to go, since it does open up the possibility of some type errors slipping through in for instance the release scripts and then only showing up as runtime error (or wrong behavior!) when we run on CI.

The tsx docs suggest possibly doing a tsc --noEmit before you run the scripts - does that make sense here?

[christian-bromann]

@alicewriteswrongs good catch 👌 I didn't know that! I pushed a change to include type checks as recommend by the tsx docs.

[alicewriteswrongs]

this is a nice way to do this 👍

[alicewriteswrongs]

oops guess those snuck through in #5698 😅

[christian-bromann]

😉

[tanner-reits]

CI error, but otherwise looks good

[christian-bromann]

CI error, but otherwise looks good

This is due to the fact that we are running the workflow from main which still uses the compiled script. Therefore I suggest to suggest merging by bypassing the protection.