feat: Refactor CLI tool #15

FDiskas · 2025-05-01T18:42:20Z

Implemented poEditorApiRequest for API communication with error handling.
Created commands for exporting translations, listing projects, and uploading files.
Added configuration loading and validation for project settings.
Introduced terminal output utilities for consistent logging.
Integrated ESLint and Prettier for code quality and formatting.
Established TypeScript types for API responses and project configurations.

I understand - this PR crazy and scary - but I will try to explain in more details:

Development Tools

Code Quality:
- TypeScript with strict typing
- ESLint for code linting (bun run lint)
- Prettier for code formatting (bun run format)
Git Hooks:
- Uses Lefthook for pre-commit hooks
- Auto-formats staged files before commit
- Runs linting on TypeScript files
Testing:
- Testing framework available through bun test

CI/CD Pipeline

GitHub Actions:
- Automated package publishing when tags starting with "v" are pushed
- Automated changelog generation
- Automated GitHub release creation with artifacts
- Contributors tracking in CONTRIBUTORS.md
Publishing Process:
- Uses Node.js v22 (specified in .nvmrc)
- Builds with Bun
- Create a new release at Github Releases page
- Create a new Tag from main branch (like: v2.0.0)
- This will automatically run build, will update package.json file with correct version
- Publishes to npm with public access (Required NPM_TOKEN secret to be specified in repository settings)
- As a maintainer - you don't need to track or update package.json version, just follow git TAG semantic versioning.

Contribution

Added contributors file
Added github action to update a list of contributors

Releasing process

Make changes
Recommended commit using Conventional Commit messages: git commit -am 'feat: Add some feature' (for fancy change log)
Push/Merge to master branch
Todo: Add github action to check PR for linting errors and run tests
Create a new Release in github Releases section
Create a new TAG from master branch
No need to add details or title just click Publish
Package should be published automatically and release page should be update to include latest changes

Update

Also update a perdition to your GITHUB_TOKEN - more info https://github.com/ad-m/github-push-action/tree/master/
Also createto github repository secret NPM_TOKEN - so github action could release a new package version

Thanks in any case. It was a good challenge for me to make this :)

- Implemented `poEditorApiRequest` for API communication with error handling. - Created commands for exporting translations, listing projects, and uploading files. - Added configuration loading and validation for project settings. - Introduced terminal output utilities for consistent logging. - Integrated ESLint and Prettier for code quality and formatting. - Established TypeScript types for API responses and project configurations.

…mprovements

zaro

I see this is a complete rewrite ( probably with some AI), which I don't mind as it looks decent, but please check my comments.

Also did you test all the functionality ?

zaro · 2025-05-02T05:12:02Z

package.json

    "url": "https://github.com/zaro/poeditorial.git"
  },
+  "scripts": {
+    "build": "bun build src/index.ts --outdir=dist --target=node --packages external --splitting",


typescript is already devDependency. What is the point of uisng bun for building ?

I for example don't use bun, so it's one step more to building.

If you publishing it from your local computer, then yes. I believe that github actions should publish the package automatically

zaro · 2025-05-02T05:13:18Z

.github/workflows/publish.yml

+
+      - name: Create Release
+        continue-on-error: true
+        uses: ncipollo/release-action@v1


This doesn't make sense I believe.
The release should be to NPM, and this is simply publising to githbub releases

Yes this is particular dedicated just for release notes.

zaro · 2025-05-02T06:49:40Z

.github/workflows/publish.yml

+          name: ${{ github.ref_name }}
+          body: ${{ steps.changelog.outputs.changes }}
+          token: ${{ github.token }}
+          artifacts: 'dist/*.js'


If this action is only for release notes, why uploading the dist/*.js files to the relase ?

In that case you can easily check the bundled output that was pushed to npm.
In some cases it's good to have it here.

You can check that already on npmjs .org. It makes no sense to me, to upload only the JS files to a release on github.

Anyway, I hавing trouble understanding your reasoning .

The whole PR looks like AI generated, which might be fine, but only if it's thoroughly tested.

Anyway, what I would sugest, so we don't waste more time is go back to the original PR, just remove the node-fetch with built-in fetch, and I'll merge and release it.

Ai generated is only the core structure and some typings from poedit swagger documentation.
Everything else like Infrastructure, release and build process I did by hand. I included my own best practices.

OK, sure.

No problem. It is not important, but here is the thing.
First this had dependency on bun . Why ? I understand you have personal preference to bun, but I have a personal preference to not care much about bun at this point.
Then, the pipelines ? What is this all about ? Just a sumple NPM publish on tag will be sufficient, but there are tons of other things, including adding compiles .js files are a release ...

I can go on, but i want to focus on the things we started talking about already ? And I want to clarify something for myself. What do you want to achieve with this total rewrite ? because refactor in the title is misleading, it is complete rewrite.

It is not super important to merge this. We can drop this problem no problem.
I took a bunjs, because he can mark external dependencies and not include in bundle. Same can be achieved with vitejs. Also bun works out of the box- no extra configuration needed. And it is fast.
Lets keep this pr for a while and improve it according to your needs and preferences

I am not against publishing from the pipeline, but if there will be publish from the pipeline at least it should be something like that : https://github.com/marketplace/actions/npm-publish
That actually publishes to NPM.

And then, bun. I am not saying bun is bad. Haven't used it , but it's interesting. My point is that anyway typescript is already a dependency, it should be used to building instead of bun.

Note I am not even talking about the massive over engineering this rewrite is. From a few hundred lines of simple script, now we have to discuss how bun is better of marking external dependencies. The truth is the script probably can be refactored w/o any external dependencies, fetch is already a built-in , and I guess the querystring built-in module can be used to construct the request body.

I hope that clarifies my standing here.

Thank you for your honest thoughts. I will improve this

FDiskas added 3 commits May 1, 2025 21:02

chore: Update workflows and configuration files for consistency and i…

e175924

…mprovements

chore: Remove unused files

25479c8

zaro reviewed May 2, 2025

View reviewed changes

feat: Refactor CLI tool #15

Are you sure you want to change the base?

feat: Refactor CLI tool #15

Uh oh!

Conversation

FDiskas commented May 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Development Tools

CI/CD Pipeline

Contribution

Releasing process

Update

Uh oh!

zaro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

FDiskas commented May 1, 2025 •

edited

Loading