Use esbuild to speed up bundling

[7ammer]

I've noticed a lot of buzz around esbuild and I was wondering if nativescript could utilise this.
I found a webpack plugin that could possibly replace 'ts-loader' and 'babel-loader' called esbuild-loader.

I've run some very quick tests on an existing Vue project:
ts-loader
ns run android --no-hmr took ~1min to startup. 😴
Reloads took ~5s

esbuild-loader
ns run android --no-hmr took ~15sec to startup. ⚡️
Reloads took ~3s

My un-minified bundle.js size is about < 2MiB

I've not tested hmr but I expect that to be faster too.

It also has a minifying option which is also fast but I've not tried it.

As an added bonus it also fixed my VUE HMR issues where editing .vue files didn't update the app. No idea why.

See the esbuild-loader readme on how to set it up.

[rigor789]

ESBuild has been certainly on my radar - very exciting tech!

I do wonder about type checking though - as far as I know esbuild strips types & doesn't do any type checking - that's left for tsc to do, however if we were to use esbuild-loader - I'm not sure where you'd see type errors if they are not shown during build/dev.

[7ammer]

The performance boost when developing is worth it for me. I also get TS errors through my IDE (phpstorm). I do see that this maybe an issue for some though.

[farfromrefug]

I ran a few tests with the webpack 5 branch and I found a big issue which prevents us to use esbuild yet. with esbuild we can't use our NativeClass decorator as esbuild does not support custom ts transformers.
i think it might be a good start to find a better way to do the nativeclass thing. i did the custom transformer because it worked right away but I never thought it was the right way to do it..

[rigor789]

@farfromrefug right - we need to implement it differently in the future (and implement the options for it, so it can replace @JavaProxy, @Objc stuff..). Until then - we'll stick with ts-loader & fork-ts-checker

[vallemar]

I think that type errors should be from the IDE. The speed of development (build) against these errors that today can be dealt with by the IDE wins by far. A recent example is vite (I think), a lot of people are moving because of that speed

[bitsnaps]

I believe vite the is new best of doing web bundling, but I know it's kinda hard to refactor all the legacy codebase from scratch.

[vallemar]

@7ammer Do you have an example repository to do this? I would like to test it or if possible even keep it as default in my projects.
Doing this in webpack.config.ts doesn't seem to do anything

       config.module
             .rule('ts')
             .test(/\.ts?$/)
             .use('esbuild-loader')
             .loader(require.resolve('esbuild-loader'))
             .options({
                 loader: 'ts',
                 target: 'es2017',
                 tsconfigRaw: require('./tsconfig.json')
             });

Could you make a flag in nativescript.config.ts to choose one or the other? This starting speed would be very very interesting.