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

UI data-url in-lining makes builds take forever #1916

Open
jpellizzari opened this issue Apr 13, 2022 · 5 comments
Open

UI data-url in-lining makes builds take forever #1916

jpellizzari opened this issue Apr 13, 2022 · 5 comments
Assignees
Labels
area/ui Issues that require front-end work bug Something isn't working

Comments

@jpellizzari
Copy link

jpellizzari commented Apr 13, 2022

The data-url inlining that was added here has made our builds take a long time and appear to have broken hot-reloading.

Reproduce:

  1. Make a trivial text change
  2. Note that the build takes ~20s
  3. Comment out all of the import statements in ui/lib/images.ts
  4. Note that the rebuild takes ~3s
@jpellizzari jpellizzari added bug Something isn't working area/ui Issues that require front-end work labels Apr 13, 2022
@jpellizzari jpellizzari self-assigned this Apr 13, 2022
@jpellizzari
Copy link
Author

jpellizzari commented Apr 13, 2022

Changing to this brings the build times down to a reasonable level:

import weaveLogo from "url:../images/WeaveLogo.svg";

My theory would be that the conversion to a base64 encoded image is taking forevs (probably happening one at a time), assuming that is what the data-url tag is doing.

HMR still not working, however.

Might be worth checking out: https://stackoverflow.com/questions/71509948/optimizing-images-using-parcel-2

@ozamosi
Copy link
Contributor

ozamosi commented Apr 19, 2022

One way out of this standoff might be to manage multiple parcelrc files? You're apparently not supposed to do that, but I can't help but think that it would actually solve the problem.

Because, the output of @parcel/transformer-raw isn't compatible with being used as a module from webpack, so we can't use url: when calling make ui-lib.

But at the same time, data-url is slow (whether because @parcel/transformer-inline-string is slow, or because @parcel/optimizer-data-url is slow, or both), so we don't want to use that when calling make ui.

But I think we could do import failedSrc from "magic:../images/failed.svg"; and create two parcelrc - one with

{
  "transformers:" {
    "magic:*": ["...", "@parcel/transformer-raw"]
  }
}

this is the same transformer as url: so it should still be fast, so we can use that locally.
And then a second one with

{
  "transformers:" {
    "magic:*": ["...", "@parcel/transformer-inline-string"]
  },
  "optimizers": {
    "magic:*": ["...", "@parcel/optimizer-data-url"]
  }
}

that's the same as data-url: so we should be able to do that in the library and have that still work in enterprise.

If we copy the appropriate one into place in the make step, then we could maybe have the behaviour we want in either case? It's absolutely a hack - I feel long term we'd save ourselves pain by using the same toolchain in both projects. But it might help?

(definitions of what each URL prefix means: https://github.com/parcel-bundler/parcel/blob/v2/packages/configs/default/index.json )

@jpellizzari
Copy link
Author

@ozamosi @foot What about if we (I) converted EE to parcel? Or maybe we can both sync on esbuild, which appears to be the new hotness?

@LappleApple
Copy link
Contributor

@jpellizzari Is this still relevant/needed/an issue?

@jpellizzari
Copy link
Author

@jpellizzari Is this still relevant/needed/an issue?

Yes still relevant. This blocks improving our FE build system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ui Issues that require front-end work bug Something isn't working
Projects
None yet
3 participants