Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Use esbuild to speed up bundling #31

7ammer started this conversation in 1. Ideas & Discussions
Feb 27, 2021 · 2 comments · 6 replies
Discussion options

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.

You must be logged in to vote

Replies: 2 comments · 6 replies

Comment options

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.

You must be logged in to vote
6 replies
@7ammer
Comment options

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
Comment options

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
Comment options

@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
Comment options

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
Comment options

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.

Comment options

@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.

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
5 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.