Open alexlafroscia opened 3 years ago
I'm fine with using a default configuration if there isn't already one.
But also realize, the whole reason we're figuring out the babel config is because we're about to invoke babel. So your app without babel will still be spending time getting parsed by babel.
The way ember-auto-import
works right now is that each file ends up parsed twice, right? Once to analyze the imports, and then later on to actually perform transformations with ember-cli-babel
?
If that's the case, I'm interested to see if replacing one of those, at least, has a positive impact on our build performance.
Correct, it could still help to eliminate one pass.
That said, people are actively trying to reduce that to one pass, meaning ember-auto-import's analysis would happen inside ember-cli-babel. https://github.com/ef4/ember-auto-import/issues/270#issuecomment-736095936
Oh, that's interesting! That's good to know; that much of an improvement many eliminate the need for my esbuild
experiment altogether.
If that work lands, and esbuild
still seems pursuing, maybe we can have a conversation about how other tools besides Babel could be supported for extracting the imports; maybe an ember-cli-esbuild
could inject a plugin in a similar manner.
Currently, this addon requires
ember-cli-babel
to also be installed by the host application. Without it, this line of code fails, sincebabelAddon
isundefined
:https://github.com/ef4/ember-auto-import/blob/7610021b3c592bcaa5a649a1d6fa799826f857d3/packages/ember-auto-import/ts/package.ts#L100
Would you be amenable to a PR that fixes this by falling back to some kind of default configuration? I am looking into an exploration of replacing Babel with ESBuild and am getting hung up on this point.