-
Notifications
You must be signed in to change notification settings - Fork 255
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
chore: switch to TypeScript #218
chore: switch to TypeScript #218
Conversation
Would like some review from @danilofuchs as well :D |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome initiative and great job!
The Typescript build is failing on a few places, please take a look at them.
@michaelwittig currently on This is currently not expressed with the current So, this PR also fixes #184 and closes #198 I would suggest returning Also, this could conflict with the work on #188 |
I resolved the ESLint config and also made the build pass by doing some casting because it is not clear some types for |
this is super hard to review. Have you changed anything expect converting to TS? @danilofuchs suggests that you also fixed a bug here? |
As far as I know, only the linked issues which are about return types being inconsistent with |
So how is this thing going to be published? So far, all I do is I don't have much time to invest in this project at the moment and I'm not involved in any frontend work at the moment. Therefore, I don't feel very confident in merging this before I know how to publish it. |
Yeah, this is a work in progress as I forget to setup the build steps for compilation and enable multiple browser supports as well. After that, the |
@KingDarBoja I see. |
When using Typescript (or any preprocessor like Babel), you have to execute a command to generate output Usually, that would be |
- remove old index.d.ts type - generate declarations
586821f
to
d24c6a5
Compare
Rebased the branch to get latest changes and also added the build script with the default |
Almost done with the whole switching as I have installed it locally in some app (using verdaccio) and works almost perfectly, just need to manage the import { getName, registerLocale } from 'i18n-iso-countries';
import { LocaleEN } from 'i18n-iso-countries/dist/langs/en';
registerLocale(LocaleEN); And rather be like: import { getName, registerLocale } from 'i18n-iso-countries';
import { LocaleEN } from 'i18n-iso-countries/langs/en';
registerLocale(LocaleEN); |
@KingDarBoja I'm not sure I liked the convertion of locale files from JSON to TS. TS can still check JSON files with the |
Does this flag let tree-shaking work with json files? My only issue is that I wasn't taking into account the lang files in the build step but since those are json files, I don't think tree-shaking applies for these. If that's the case, that means converting JSON files to JS or something that can be tree-shakable with tools like Webpack or Rollup but never tried such ways as TS compiler can do the job with TS files. |
@danilofuchs after trying out some stuff, I made it work as you expected while keeping the import { getName, registerLocale } from 'i18n-iso-countries';
import { COUNTRY_CODES } from 'i18n-iso-countries/codes';
import { localeEN } from 'i18n-iso-countries/bundled'; Kinda based on the #188 but without rollup, while relying on some workarounds due to TS lack of support for subpath exports from NodeJS v12+. package.json {
"typings": "dist/index.d.ts",
"main": "dist/entry-node.js",
"browser": {
"./dist/entry-node.js": "./dist/index.js"
},
"exports": {
".": {
"import": "./dist/index.js"
},
"./codes": {
"import": "./dist/codes.js"
},
"./bundled": {
"import": "./dist/entry-node.js"
}
},
"typesVersions": {
"*": {
"codes": ["dist/codes"],
"bundled": ["dist/entry-node"]
}
},
} Still have some errors on the consumer side but guess it is a progress. Looks like it is caused by webpack 4 (as I am testing it in a Angular 11 project):
Update 1At the end, decided to keep the TS conversion of those json files as it gave me some headaches trying to structure into the final bundle. Also managed to make the langs imports to work as below in some Angular 11 app I used for playing around: import { getName, registerLocale } from 'i18n-iso-countries';
import { LocaleEN } from 'i18n-iso-countries/langs';
@Component({ })
export class AppComponent {
constructor() {
registerLocale(LocaleEN);
console.log(getName('co', 'en')); // Colombia
console.log(getName('co', 'es')); // undefined
}
} Only downside is that I exported all locales in a barrel Update 2After tweaking a bit the base |
Converted dv and sw json files to TS files.
Any more progress / work arounds for using a single locale?, especially with angular where it builds an entire app per locale, having every locale in the bundle is a bit of a bloat |
While waiting for this PR, I am making a flag pack library that relies on this package but to enable tree-shaking of unused lang files, I have copied the source code into its own library (not released yet): https://github.com/KingDarBoja/ngx-nations Probably gonna call it |
Any news regarding this PR? |
any plans to merge this into master at some point? |
@bschnabel I don't think that the work here is done. More like a WIP. Correct me if I'm wrong @KingDarBoja ? |
Almost 2 years have passed since last update so I can't remember if there was something missing. Probably not, maybe some conflict updates there and there but I am no longer interested in continuing with this PR (no free time for it). Hope someone else completes this one if the TypeScript conversion is still wanted 😄 |
@KingDarBoja I see. Let me close this PR. |
This is a work in progress. References #176
Changelog:
types.ts
file.index.d.ts
file and set compiler flag to autogenerate those from src.localeFilter
type definitions(Need some help here!)casted in the meantime 🧙 .