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

Feature/multiple loaders and cli #547

Conversation

vsamofal
Copy link
Collaborator

@vsamofal vsamofal commented Aug 21, 2023

Description

I implemented 3 features, one small, and two that actually broke existing functionality.

  1. I added the ability to parse a response formatted, so everyone will be able to customize it if needed.
  2. I implemented a cli to generate types and watch for generation, pointing to multiple folders. (this one doesn't support custom loaders yet, but it's possible to implement it as well if someone needs it). Now only json and yaml supported
  3. also, I added the ability to specify multiple loaders. for me it is useful with mono repo, or when some library provides default translations, so I can load it. My specific use case is to package validation errors and distribute them across the organization
  4. also fixed all eslint and prettier issues

I also need to update the documentation if these changes are ok to do, also it's a breaking change probably, version 11 makes more sense.

I don't expect this pr to be merged, but more to have a conversation about all of these changes.

Thanks

Linked Issues

Additional context

the easiest way to test a client is to

npm install @saas-buildkit/nestjs-i18n
nestjs-i18n -h

added ability to pass an optional custom response body formatter
fixed tests that become broken accidently
made fixes to make it work properly
removed watch mode because I don't like even idea to generate it in runtime
…ders

renamed base methods for validations to make code cleaner
improvements for tests and imports
did a lot of manual testing for the cli with different situations for json
…s_client

Feature/proper generate types client
…s_client

updated version and added changing permissions for cli file after build
Copy link
Collaborator

@rubiin rubiin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as long as no tests break fine with me. For the cli feature, @toonvanstrijp will have to give his confirmation

…s_and_cli

# Conflicts:
#	package.json
#	samples/dto-validation/src/app.module.ts
#	samples/simple/src/app.controller.ts
#	samples/simple/src/app.module.ts
#	src/i18n.constants.ts
#	src/i18n.module.ts
#	src/loaders/i18n.abstract-file.loader.ts
#	src/loaders/i18n.json.loader.ts
#	src/loaders/i18n.loader.ts
#	src/loaders/i18n.yaml.loader.ts
#	src/resolvers/header.resolver.ts
#	src/resolvers/query.resolver.ts
#	src/services/i18n.service.ts
#	src/utils/merge.ts
#	src/utils/typescript.ts
#	tsconfig.json
…conds just for safety and play with debounce
# Conflicts:
#	tests/i18n-fastify.e2e.spec.ts
@coveralls
Copy link

coveralls commented Aug 22, 2023

Coverage Status

coverage: 87.259% (-3.6%) from 90.828%
when pulling 38dffc3 on saas-buildkit:feature/multiple_loaders_and_cli
into 2eb5f4e on toonvanstrijp:main.

@vsamofal
Copy link
Collaborator Author

I did fix all issues with pipelines.

@toonvanstrijp let me know when you can take a look and approve the work, so I can do the documentation part, and because of the breaking change it probably will be 11.0.0?

Copy link
Owner

@toonvanstrijp toonvanstrijp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vsamofal awesome work so far! I'm really happy and grateful for the effort you're putting in. I think with a few more things to discuss we could make an awesome V11 release that's going to take this library in the right direction!

@@ -0,0 +1,17 @@
#!/usr/bin/env node
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vsamofal I'm a very big fan of this feature! One of the early versions of nestjs-i18n had this feature implemented. But I think we could even improve on this a little bit more.

What if we move the I18nOptions to a file (e.g. i18n.ts) just like how mikro-orm does it too. That way we make the i18n-cli use that config, but also let the nestjs module use that config.

This would end up with a better workflow and configuration.

this.events.pipe(switchMap(() => this.parseTranslations())),
);
}
async load(): Promise<I18nTranslation> {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might need to be careful with removing the Observable as a return type. If we change it to a promise instead, it won't be possible to have translation be loaded in real time or be pushed be some other event. This means you would need to call refresh yourself whenever is needed. What are your thoughts on this @rubiin ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. Promise and Observables work differently. Observables are mostly preferred way of working with streams i.e series of data unlike promises which would mostly resolve a single value and be done

loaderOptions: {
path: path.join(__dirname, '/i18n/'),
},
loaders: [
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it still possible to use dependency injection in the loader? Now if you loader for example used your mikro-orm connection it won't be possible to inject this. Maybe we need to rethink the loader options a bit. Since if we're going to make breaking changes for a V11, we can make a few more to change this we don't particularly like now.

# Conflicts:
#	package-lock.json
#	package.json
#	src/i18n.context.ts
#	src/i18n.module.ts
#	src/index.ts
#	src/loaders/i18n.abstract-file.loader.ts
#	src/loaders/i18n.json.loader.ts
#	src/loaders/i18n.yaml.loader.ts
#	src/services/i18n.service.ts
@vsamofal
Copy link
Collaborator Author

vsamofal commented Oct 4, 2023

@rubiin @toonvanstrijp Hi guys, when you have time can you take a look

@rubiin
Copy link
Collaborator

rubiin commented Oct 5, 2023

Will be cherry picking some commits that are no breaking

@rubiin rubiin mentioned this pull request Oct 5, 2023
@thiagotognoli
Copy link

@rubiin @toonvanstrijp Hi guys, when you have time can you take a look

please approve this pr, we need these changes

"main": "./dist/index.js",
"types": "./dist/index.d.ts",
"files": [
"dist"
],
"scripts": {
"prepare": "npm run build",
"postbuild": "chmod +x ./dist/cli.js",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need to set execution mode?

return newPath.startsWith('./') ? newPath.slice(2) : newPath;
}

function sanitizePaths(paths: string[]) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it work for win system?


function sanitizePath(path: string) {
// adding trailing slash
const newPath = path.endsWith('/') ? path : `${path}/`;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we use node:path.parse function?

catch(exception: I18nValidationException, host: ArgumentsHost) {
const i18n = I18nContext.current();

const errors = formatI18nErrors(exception.errors ?? [], i18n.service, {
lang: i18n.lang,
});

const normalizedErrors = this.normalizeValidationErrors(errors);

switch (host.getType() as string) {
case 'http':
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we process the 'rpc' context type?

@@ -0,0 +1,80 @@
import fs from "fs"
import path from "path"
import {pathToFileURL} from "url"
Copy link

@B0ER B0ER Oct 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here it's not formatted, but
I'm not sure that it was needed to re-format all to another code-style, definitely imports, order of import and private\public methods
(if it's prettier fix - ok)

@@ -6,11 +6,14 @@
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"skipLibCheck": true,
"importHelpers": false,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why you turn off importHelpers?

# Conflicts:
#	package-lock.json
#	samples/dto-validation/pnpm-lock.yaml
#	samples/simple/pnpm-lock.yaml
#	src/filters/i18n-validation-exception.filter.ts
#	src/i18n.context.ts
#	src/i18n.module.ts
#	tests/app/controllers/hello.controller.ts
#	tests/app/examples/example.functions.ts
#	tsconfig.json
Repository owner deleted a comment from B0ER Apr 22, 2024
@rubiin
Copy link
Collaborator

rubiin commented Apr 22, 2024

Lets break the changes into different PR . Would be easier to review and rollout considering the breaking changes.

@rubiin
Copy link
Collaborator

rubiin commented Apr 24, 2024

closed in favor of #628

@rubiin rubiin closed this Apr 24, 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.

6 participants