🚀 2.0.0 - Parser instead of Regex?

[aralroca]

Babel

@marcesengel did a great contribution replacing all regular expressions to a babel parser #854 It is likely to solve many of the current issues and prevent future issues.

However, it is a big core change, and I propose to release it for version 2.0.0.

Currently prerelease to try: 2.0.0-experimental.1, please try it.

---

TypeScript compiler

Another Proposal by @StLyn4: TypeScript compiler:

PR: #913

Possible to try it in 2.0.0-experimental.3

---

I look forward to your feedback on these changes.

[slevy85]

If next-translate uses a babel parser, does it mean that next will not use SWC ?

[StLyn4]

No, both versions (babel/ts) work regardless of the build settings of the project itself.
That is, whichever version is used, it will not affect the settings of the project.

By the way, I don't know about babel, but ts version works with both ts and js

[finkrer]

As far as fixing #827 is concerned, the TypeScript version works and the Babel version doesn't.

Not sure if there are other differences, but I would just use the TS version.

[marcesengel]

Hey @aralroca, I'd be open to fix the bugs with the babel parser, we just need to add a test for the failing case and it'll be good to go in no time. However the typescript compiler also looks good to me, in the end it really doesn't make a difference. Both tools generate AST for the source code, it just looks slightly differently.
However I'd suggest adding typescript as a peer dependency, because we don't want to bring our own version, do we?

[marcesengel]

After having a look again, I'd say if there's any difference, it's that the babel version also uses AST to generate the added code.

[StLyn4]

Hey @aralroca, I'd be open to fix the bugs with the babel parser, we just need to add a test for the failing case and it'll be good to go in no time. However the typescript compiler also looks good to me, in the end it really doesn't make a difference. Both tools generate AST for the source code, it just looks slightly differently.

However I'd suggest adding typescript as a peer dependency, because we don't want to bring our own version, do we?

If I'm not confused, in that case the library will give a warning (or crash altogether) when trying to use in a project without TypeScript. Correct me if I'm wrong. In case of normal dependencies, the TypeScript module will simply be loaded twice in node_modules, which should not conflict with each other (this also saves us from possible crashes in case of a major TypeScript update). If the versions are the same, even better

[StLyn4]

After having a look again, I'd say if there's any difference, it's that the babel version also uses AST to generate the added code.

I also thought about doing it that way at first, but then left it as it was (the method with the template). I think it's more obvious what the final code should look like. But maybe it's just my taste

[marcesengel]

Hey @aralroca, I'd be open to fix the bugs with the babel parser, we just need to add a test for the failing case and it'll be good to go in no time. However the typescript compiler also looks good to me, in the end it really doesn't make a difference. Both tools generate AST for the source code, it just looks slightly differently.
However I'd suggest adding typescript as a peer dependency, because we don't want to bring our own version, do we?

If I'm not confused, in that case the library will give a warning (or crash altogether) when trying to use in a project without TypeScript. Correct me if I'm wrong. In case of normal dependencies, the TypeScript module will simply be loaded twice in node_modules, which should not conflict with each other (this also saves us from possible crashes in case of a major TypeScript update). If the versions are the same, even better

When using yarn it takes care of the peer dep for you AFAIK, with npm you get at least a warning every time you run an install. I'd do it this way, because a good percentage of our users will already have an installation of typescript - if every tool consuming ts brings its own version, it can get very messy. However npm and yarn will also try to dedupe shared dependencies, meaning that if we add a dependency for ^4.9.3 every consumer using typescript@4.x.x will not have a second version added, so in the end a normal dependency should also be fine as it won't really make a difference unless we're in a project not using the same major version. Then peer deps would be inferior.

After having a look again, I'd say if there's any difference, it's that the babel version also uses AST to generate the added code.

I also thought about doing it that way at first, but then left it as it was (the method with the template). I think it's more obvious what the final code should look like. But maybe it's just my taste

Yeah I definitely see the point. To me using AST felt like the better idea because in order to prevent naming conflicts every variable would need a dynamic name anyways, at which point a template string would look pretty messed up.

@StLyn4 nice work on your end 👍

[finkrer]

For what it's worth, I've been using the TS version (experimental.3) in production for a couple of months now without any issues.

[aralroca]

Thanks, great news

[aralroca]

We ultimately decided to implement @StLyn4's version using the TypeScript parser.

Although we ultimately decided to go with the TypeScript parser, we would like to acknowledge and thank @marcesengel for their contributions. @all-contributors please add @marcesengel for code.

I have decided to create a separate package, called next-translate-plugin, to handle the Webpack plugin functionality in the next-translate library. This decision was made to improve the overall performance and maintainability of the library. By separating the plugin functionality into its own package, we can ensure that it is only loaded during the build process and not included in the final bundle that is served to the client, reducing the final bundle size. Additionally, by listing it as a devDependency, it will be installed only in development environment and not in production. This also allows for better management of the plugin and its dependencies, and makes it easier to update or change in the future, if needed.

For those interested, you can see the pull request for the changes here: #975

And the new package next-translate-plugin can be found in this repository https://github.com/aralroca/next-translate-plugin

Thank you both again for your contributions and support in making this library better. And any feedback on the PR is very welcome 😊

[aralroca]

You can try it now in 2.0.0-canary.2. Requires next-translate-plugin with this version 2.0.0-canary.6.

yarn add next-translate-plugin@2.0.0-canary.6 -D

• Docs on how to migrate to 2.0.0: https://github.com/aralroca/next-translate/blob/canary/docs/migration-guide-2.0.0.md
• Next-translate-plugin repository: https://github.com/aralroca/next-translate-plugin

Now the next-translate size reduces it 😊 Less work for some pipelines 👍

[marcesengel]

Smaller runner stages when using Docker 🥳 I like it!