Replace webpack with esbuild.

[nojaf]

Fixes #1672.
Followed the instructions at https://code.visualstudio.com/api/working-with-extensions/bundling-extension#using-esbuild.
The watch target is no longer building, I was able to run the launch target after Fable compiled the files.
What a world we live in.

[MangelMaxime]

Hello,
hum in this PR @nojaf you are removing yarn.lock file which is not related to webpack.

I think this is an error on your side or that your changes are incomplete as yarn is still used in the build script

ionide-vscode-fsharp/build/Program.fs

Lines 279 to 280 in 69889cc

	Target.create "YarnInstall"
	<| fun _ -> Yarn.install id

or even the workflow:

ionide-vscode-fsharp/.github/workflows/pr.yml

Line 30 in 69889cc

- run: yarn global add vsce

[nojaf]

Hey Maxime, good spot, I indeed did not indent to remove the yarn lock but commit the modified version.
I rectified this.

[MangelMaxime]

@nojaf TBH I think I originally missread the PR 😅

When I saw -3,462 lines I looked for the cause of all that removal and saw that it was the yarn.lock and thought that you deleted it. But I think, you had just the changes published originally. Oops

[nojaf]

Aha, I see, yeah swapping this is good for the node_modules footprint.

[AngelMunoz]

Hey hope you don't mind this, I re-tried to remove webpack from the toolchain in #1722 I don't think we need esbuild (preprocess javascript) at all so I went with rollup (just bundles and tree-shakes)

in terms of bundling rollup is more flexible (but still simpler than webpack by a mile or two) and could allow us to work in some more complex webviews in the future

Feel free to let me know if that works or should we stick with esbuild

[nojaf]

Hello, I do kinda mind actually. Esbuild is literally listed as the first item on the docs https://code.visualstudio.com/api/working-with-extensions/bundling-extension.

You don't go into detail about why rollup is the better fit, so why should we deviate from what is recommended?

I don't think we need esbuild (preprocess javascript)

That is an assumption, you don't know what old vscode version is going to be used (older electron, older V8 runtime). Nor are you considering cloud IDE scenario's where older browsers might be a thing due to company policies.

[AngelMunoz]

Of course, let me formulate

Fable emits ES2015 compatible code, which means every browser from 2016~2017 already supports it, thankfully Internet Explorer is already EoL, in the case of electron it is tightly coupled to the chromium engine, so it supports ES2015 from around the same time, in the case of node.js the ES2015 support was introduced around version 8, and full support was fully added in node 10 AFAIK both this versions have gone EoL as well, so I can feel quite safe saying that we won't face any particular issue with browser vendors or electron version, even if they date back a couple of years old which even then it would be very bad for security purposes of any company if that was the case

Esbuild is literally listed as the first item on the docs

Esbuild is not the only one mentioned in the docs, in the brief mention on all of them rollup is actually the first mentioned but I digress

For JavaScript, different bundlers are available. Popular ones are rollup.js, Parcel, esbuild, and webpack.

Rollup is a better fit from a configuration standpoint, rollup can provide multiple bundles if necessary (a simple example can be seen here) which could be really useful for vscode webviews,I made some discoveries in that area in #1721, it has a broad set of plugins and a healthy ecosystem and it is often used as the bundler for popular tools like vite, which uses esbuild for the transpilation but leverages rollup even for it's plugin API

Vite plugins extends Rollup's well-designed plugin interface with a few extra Vite-specific options. As a result, you can write a Vite plugin once and have it work for both dev and build.

It is recommended to go through Rollup's plugin documentation first before reading the sections below.

If Ionide authors were not using fable for the codebase I would favor esbuild given that one may want to use decorators today or private javascript properties or some form of newer syntax but thankfully that's not the case I do believe we don't need any kind of transpiling to older javascript and only the bundling flexibility is needed in this project

On a tangent note and to ensure I meant no harm, I'm sorry if I didn't phrase well on my other PR but my "serious attempt" was not because of your PR, it was because my not so serious attempt was this comment (which if you check that comparison doesn't even exists anymore) that I left on the issue you opened not because I don't think your PR is serious that was a really bad phrasing on my part

[nojaf]

can provide multiple bundles

You could have multiple invocations of esbuild if you need that.

a better fit from a configuration standpoint

Replacing the webpack config with a rollup will have similar story beats: there is a config file nobody wants to touch and there are multiple npm packages involved where updating a single one of them can be a lot of fun. I kinda liked the esbuild approach, where it is a single binary, single command and light footprint in terms of node_modules. From that point of view, rollup seems like a step back under the pretence that it will solve future problems which I don't see yet right here, right now.

If we are certain that the ES20XX code by Fable runs everywhere I'd even be in favour of not bundling at all. It seemed the safest thing to do, but if that is a thing of the past then there is no need.

[MangelMaxime]

@nojaf Bundling still makes sense nowdays because:

• You can minify the code and so there are less stuff to access
• Remove the comments which don't need to parse at runtime
• Don't need to access severals files to load but only a single one (true it means loading everything at once instead of on the needs)

My 2 cents, is that if esbuild does the job let's use it. If in the feature we need specific features that esbuild doesn't support it is always possible to revisit the build process.

[AngelMunoz]

Replacing the webpack config with a rollup will have similar story beats: there is a config file nobody wants to touch and there are multiple npm packages involved where updating a single one of them can be a lot of fun.

The libraries surrounding rollup are fairly more stable and the packages needed are actually updated by the core rollup team, we don't need to depend on packages outside core, in any case the configuration for rollup is far simpler than that of webpack, we don't need to meddle with loaders and weird resolution rules, since rollup is meant to be used with modern javascript.

the other libraries I installed on that PR were actually undeclared dependencies (we were using them but because of the flat modules of yarn/npm it was easy to require them by any package we used)

I kinda liked the esbuild approach, where it is a single binary, single command and light footprint in terms of node_modules.

I agree there it's a simpler alternative and in conjunction with pnpm disk footprint can lower down quite a lot (improving CI times as well)

From that point of view, rollup seems like a step back under the pretence that it will solve future problems which I don't see yet right here, right now.

If we are certain that the ES20XX code by Fable runs everywhere I'd even be in favour of not bundling at all. It seemed the safest thing to do, but if that is a thing of the past then there is no need.

I actually asked that question #1672 (comment) whether we wanted bundling or not

I don't think we do, but if we need to bundle anyway because the docs says it is a good practice I personally would trust more rollup than esbuild in that aspect but that's just personal opinion

[AngelMunoz]

Well... I think we do need bundling now that I remember

microsoft/vscode#130367

vscode extensions don't seem support ESModules (although node does) we need to have a commonjs bundle/output I stumbled upon this when I was moving to rollup on my PR

other point I think we're both missing was that Chet mentioned we should include the F# sourcemaps for better debugging