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

ts-node #18

Open
artemdemo opened this issue Jan 17, 2023 · 1 comment
Open

ts-node #18

artemdemo opened this issue Jan 17, 2023 · 1 comment

Comments

@artemdemo
Copy link

Hey,

We are absolutely loving using code-migrate in our company, it's been a game changer for us.

But, we've hit a snag. code-migrate currently relies on ts-node to run our TypeScript code, but unfortunately it doesn't come with typescript included. This means we have to manually add it to our toolkit, and that's just not cool.

We have a proposal that we think will take code-migrate to the next level. By replacing ts-node with a runner that doesn't require typescript, such as tsx, we'll be able to streamline our workflow and make our lives so much easier.

wdyt?

@ranyitz
Copy link
Owner

ranyitz commented Jan 17, 2023

Thanks for opening this issue!

The initial idea for using ts-node and not providing TypeScript was:

  1. performance is not the primary concern when running these migrations, and transpiling the migration code is relatively fast even when it happens on the fly.
  2. TypeScript tends to break its API between minor versions and I didn't want to couple the version of code-migrate with the version of TypeScript being used.

2 years ago, when this project was created tsx was just a cool idea. by replacing ts-node, we'll be able to get the following benefits:

  1. Faster compilation
  2. No need to bring TypeScript

The only drawback that I see here is the install size:

Considering the size of code-migrate today (including its dependencies) is: 2.07Mb

This was also a concern when deciding to provide babel instead of swc in vite

image


After considering the install size, we should consider the following options:

  1. switch to using babel by default for the transformations - good balance between transpilation time and install time, considering many transpilations use babel anyway
  2. Continue to use ts-node by default
  3. Enable an option to have a custom transpiler - the migration writer will choose their own transformation logic

@artemdemo what do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants