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

Boilerplate Redesign #400

Closed
Jonghakseo opened this issue Feb 25, 2024 · 3 comments · Fixed by #425
Closed

Boilerplate Redesign #400

Jonghakseo opened this issue Feb 25, 2024 · 3 comments · Fixed by #425

Comments

@Jonghakseo
Copy link
Owner

Jonghakseo commented Feb 25, 2024

Redesign this project

Problems with Boilerplate

  1. single build pipeline, which means that every code change on a specific page (Popup) causes a new build of the entire project, which significantly slows down the build speed as the project grows.
  2. difficult to understand the codebase due to many custom elements, such as vite-preload inline plugin, cache Invalid plugin.
  3. the current approach of (essentially) hacking the entryPoint of Vite and rollup does not allow for further evolution.

How I want to improve (draft)

  1. improve to a turborepo-based monorepo approach: leverage turborepo's build cache, pipeline orchestration, and other features to optimize build times for each page and shared resources.
  2. introduce faster bundlers (e.g. esbuild) for backgrounds, etc. that don't need to use vite
  3. add validation for manifests.
  4. internalized Hot Rebuild & Reload feature in development stage so that users don't need to declare refresh method directly.

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.

@Jonghakseo Jonghakseo added the enhancement New feature or request label Feb 25, 2024
@Jonghakseo Jonghakseo self-assigned this Feb 25, 2024
@Jonghakseo Jonghakseo pinned this issue Feb 25, 2024
@Jonghakseo Jonghakseo added high priority redesign and removed enhancement New feature or request labels Feb 25, 2024
@sumbatx15
Copy link

sumbatx15 commented Apr 27, 2024

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

@Jonghakseo Jonghakseo linked a pull request May 11, 2024 that will close this issue
4 tasks
@Jonghakseo
Copy link
Owner Author

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: 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 :)

@PatrykKuniczak
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants