-
-
Notifications
You must be signed in to change notification settings - Fork 386
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
Boilerplate Redesign #400
Comments
I'm using this boilerplate, and it's great, but the build times are crazy. So, I've tried to come up with something to make it faster and then I found this: https://crxjs.dev/vite-plugin. It's a plugin for Vite. Now, in the vite config, I only have the React plugin and this one. And it's the best because you just run 'vite dev,' and it works like a normal vite project (super fast). Check it out before you start this big refactor. Actually, this could be a great thing to add to this boilerplate |
Thanks for the nice comment. To be honest, I've been deeply inspired by the project you mentioned and have been admiring its internal implementation since it first appeared. However, that project and the direction I want to go are different, and here's why. That project is a sophisticated plugin, implemented by tweaking vite's devServer implementation to output to local files. (genious!) My project, on the other hand, is boilerplate and aims for base code that users can change relatively easily in the future (so that they can easily customize it into their own project). If I were to use that plugin in my project, my boilerplate project would be very directly dependent on it. This means that the vite and esbuild ecosystems that it relies on will also be more tightly coupled. I hope you can understand that this is a different direction of thinking and therefore a different direction of implementation, Thanks :) |
I was tried to implement i18n, it's possible but not that easy, cause of the current turborepo structure, if you want to use the translation in one module, then this module have in the output files, the message.json(with translation), and the entry point of the module index file, was changed cause of the difference in the folders structure. I know there's some extra features like interpolation, and i18n works good with React, but IMO the i18n chrome extension approach is good, and don't need any extra modules. As you describe above, the boilerplate is 'difficult to understand', and we need to consider if this is really necessary, cause of the translation in '_locals' is easy to use. I'm open to discussion <3 |
Redesign this project
Problems with Boilerplate
How I want to improve (draft)
Expected Phase
1st
Proof of concept, basic setup of the project and bundler testing.
2nd
Finalize HRR functionality for each module
3rd
Adding additional features such as manifest validation, bundler optimization, i18n, etc.
Expect each phase to take 2 weeks to 1 month.
The goal is to finish the complete transition within the first half of the year and replace the current main branch with the redesign branch.
The text was updated successfully, but these errors were encountered: