5 ms·

> instead of hand rolling your build commands and configs, just use Vite[1] already. For greenfield projects? Certainly. For existing projects? Oh, you're in f

> instead of hand rolling your build commands and configs, just use Vite[1] already. For greenfield projects? Certainly. For existing projects? Oh, you're in for a world of pain. I'm all for breaking with the old and ushering the new era in, but there should be an upgrade path for as many possible combinations of the old as possible. As luck would have it I decided to convert our project to vite to see if it's feasible. So far it's: - Absolute imports don't work and are broken in any number of subtle ways We use typescript with a setup that resolves `/our-stuff` to `./src`. Also this is served from `http://our-server/our-stuff http://our-server/our-stuff` because we're a part of a larger app. Good luck making this work with vite. Somehow it insists that you should replace all absolute imports with `/@/` and setup an alias for that. All other options (like using vite-tsconfig-paths) will not work because vite's `base` config will break this. I "solved" it by listing all directories in `src` and converting them into vite aliases. - Now I'm stuck with `[vite] Internal server error: failed to resolve "extends":"../../tsconfig.json" in <some-path>/mui-theme/tsconfig.json` How to fix it? Hell if I know. At this point I'm just giving up, and looking into how to maybe upgrade to webpack 5.

oefrha 5y ago
Point taken, but it's not like switching the average existing webpack project (let alone a webpack 4 project) to esbuild is just a walk in the park. We're talking about whether you should roll your own esbuild commands here.
- dmitriid 5y ago
  Yeah, it looks like rolling our own esbuild commands might be the way to go because "just switch to vite already" doesn't work, does it?
  - oefrha 5y ago
    If you can roll your own esbuild commands to build your codebase without change, good for you. Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that.
    - dmitriid 5y ago
      > Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that. Because vite does, and "just go with vite", right?
      - oefrha 5y ago
        Because when it actually works it's a very refreshing development experience, once you get used to it you never want to return to the crappy "let me refresh this page to see my changes" workflow. But hey, tons of people swear by the simple setup they claim to understand; good for them. As someone who don't work on frontend stuff professionally, I wouldn't pretend I "understand" esbuild and can always fix it when it breaks. Ironically, TFA presents an issue with this simple setup that the author could not figure out without help from experts: > I was really baffled by this, but I was eventually able to figure it out with some help from people who understood Javascript.
lhnz 5y ago
The sane option would be to use a codemod to rewrite your code to not need bespoke tooling configurations. You are locking yourself into legacy tooling.
- dmitriid 5y ago
  > The sane option would be to use a codemod to rewrite your code to not need bespoke tooling configurations. 1. Absolute paths are not "bespoke tooling config", it's a tsconfig setting 2. Requiring some code to be served from a specific url is not "bespoke tooling config", it's a requirement for quite a few projects 3. Forcing someone to mindlessly and absolutely needlessly re-write thousands of import statements isn't really a solution 4. This will still not fix "failed to resolve "extends":"../../tsconfig.json"" and who knows what other errors
  - ComputerGuru 5y ago
    > Forcing someone to mindlessly and absolutely needlessly re-write thousands of import statements isn't really a solution This is how progress is measured in the web world. The impact of your code/project/patch is measured by how many lines have to be rewritten to adopt it. The higher the number, the better your web wizardry rank is.
Griffinsauce 5y ago
Your best bet is to try and remove as much config as possible first. Simplify and then migrate or upgrade. Webpack allows you to paint yourself so far into a corner that it becomes impossible to move anywhere. We should see this for what it is: an existential threat for your app. It eventually grinds everything to a halt.
- dmitriid 5y ago
  > Your best bet is to try and remove as much config as possible first. Which config? > Webpack allows you to paint yourself so far into a corner https://news.ycombinator.com/item?id=29239108 https://news.ycombinator.com/item?id=29239108

oefrha 5y ago

Point taken, but it's not like switching the average existing webpack project (let alone a webpack 4 project) to esbuild is just a walk in the park. We're talking about whether you should roll your own esbuild commands here.

dmitriid 5y ago
Yeah, it looks like rolling our own esbuild commands might be the way to go because "just switch to vite already" doesn't work, does it?
- oefrha 5y ago
  If you can roll your own esbuild commands to build your codebase without change, good for you. Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that.
  - dmitriid 5y ago
    > Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that. Because vite does, and "just go with vite", right?
    - oefrha 5y ago
      Because when it actually works it's a very refreshing development experience, once you get used to it you never want to return to the crappy "let me refresh this page to see my changes" workflow. But hey, tons of people swear by the simple setup they claim to understand; good for them. As someone who don't work on frontend stuff professionally, I wouldn't pretend I "understand" esbuild and can always fix it when it breaks. Ironically, TFA presents an issue with this simple setup that the author could not figure out without help from experts: > I was really baffled by this, but I was eventually able to figure it out with some help from people who understood Javascript.

lhnz 5y ago

The sane option would be to use a codemod to rewrite your code to not need bespoke tooling configurations. You are locking yourself into legacy tooling.

dmitriid 5y ago
> The sane option would be to use a codemod to rewrite your code to not need bespoke tooling configurations. 1. Absolute paths are not "bespoke tooling config", it's a tsconfig setting 2. Requiring some code to be served from a specific url is not "bespoke tooling config", it's a requirement for quite a few projects 3. Forcing someone to mindlessly and absolutely needlessly re-write thousands of import statements isn't really a solution 4. This will still not fix "failed to resolve "extends":"../../tsconfig.json"" and who knows what other errors
- ComputerGuru 5y ago
  > Forcing someone to mindlessly and absolutely needlessly re-write thousands of import statements isn't really a solution This is how progress is measured in the web world. The impact of your code/project/patch is measured by how many lines have to be rewritten to adopt it. The higher the number, the better your web wizardry rank is.

Griffinsauce 5y ago

Your best bet is to try and remove as much config as possible first. Simplify and then migrate or upgrade. Webpack allows you to paint yourself so far into a corner that it becomes impossible to move anywhere. We should see this for what it is: an existential threat for your app. It eventually grinds everything to a halt.

dmitriid 5y ago
> Your best bet is to try and remove as much config as possible first. Which config? > Webpack allows you to paint yourself so far into a corner https://news.ycombinator.com/item?id=29239108 https://news.ycombinator.com/item?id=29239108