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

Move to Typescript #579

Closed
wants to merge 18 commits into from
Closed

Move to Typescript #579

wants to merge 18 commits into from

Conversation

djfjfofoc3
Copy link

@djfjfofoc3 djfjfofoc3 commented Mar 20, 2022

Changes

This PR introduces a few changes:

  1. Move to TypeScript (duh) - This also means there are now auto-generated typescript definitions
  2. Make test cases use node 14.x and 17.x, rather than just 14.x
  3. Use eslint directly; standard complains about typescript's syntax
  4. Update Dependencies
  5. Add names to each CI/CD step
  6. Move linting to a seperate workflow, to avoid unnecesary linting for each node version
  7. Add TypeScript examples/basic.ts
  8. Make package.json:engines.node be >=14 instead of the previous >=8

In terms of TypeScript types, there's a lot more to be desired, however this is definitely an improvement over vanilla JS.

Compatability

This, in theory, shouldn't break any dependents, unless they directly import files in the src directory.

Other things of note

src/lib/plugins/log.ts:49 Removed this weird code that my tsc was complaining about - don't really know why it's there, maybe someone here can re-implement this in a non-broken way.


Conventional Commits Fixes #533

MokiyCodes and others added 18 commits March 20, 2022 17:25
This moves to TypeScript, and directly uses ESLint because standard complained about typescript

todo: fix the 31 eslint warnings

semi-breaking: You now need to build the project using `pnpm build`/`yarn build`/`npm run build`
The main .gitignore file now ignores *.log (see 47e9ccd), so this .gitignore is unnecesary
Somehow the commit where I actually changed this, didn't change it in git (wtf)
This is done to (a) save time, and (b) because the 16.x workflow for mcVersionIndex 8 takes slightly too long in CI/CD
@djfjfofoc3
Copy link
Author

This also fixes #323

@rom1504
Copy link
Member

rom1504 commented Mar 20, 2022

can you instead follow the same technical choice we made for the rest of PrismarineJS: adding a .d.ts file and keeping the code in javascript?

@djfjfofoc3
Copy link
Author

can you instead follow the same technical choice we made for the rest of PrismarineJS: adding a .d.ts file and keeping the code in javascript?

Sure - I'll do that when I have time for that.

@IceTank
Copy link

IceTank commented Mar 20, 2022

src/lib/plugins/log.ts:49 Removed this weird code that my tsc was complaining about - don't really know why it's there, maybe someone here can re-implement this in a non-broken way.

This looks like it is patching console.log in a way where it will always put the cursor at a certain position once called. It is probably to make the command line cleaner once stuff has been logged to it. Just like the vanilla minecraft server dose it. No wonder it is throwing linting errors because it overwrites the default console.log. The 'real' way to patch this is to make a new custom logging function and change all console.log to that.

@djfjfofoc3
Copy link
Author

src/lib/plugins/log.ts:49 Removed this weird code that my tsc was complaining about - don't really know why it's there, maybe someone here can re-implement this in a non-broken way.

This looks like it is patching console.log in a way where it will always put the cursor at a certain position once called. It is probably to make the command line cleaner once stuff has been logged to it. Just like the vanilla minecraft server dose it. No wonder it is throwing linting errors because it overwrites the default console.log. The 'real' way to patch this is to make a new custom logging function and change all console.log to that.

My tsc was complaining, not my eslint - eslint was pretty silent for it.

@Bezouro
Copy link

Bezouro commented Dec 10, 2023

can you instead follow the same technical choice we made for the rest of PrismarineJS: adding a .d.ts file and keeping the code in javascript?

@rom1504
Doesn't this mean more work to maintain the project?
Why go this way when we can have the code already in typescript?

@zardoy zardoy mentioned this pull request Jan 7, 2024
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

Successfully merging this pull request may close these issues.

4 participants