Devbuild on esbuild

[mbrzakovic]

Switched devbuild from rollup to esbuild.

• Reasoning: Faster dev build (now: 0.3s, was: 12s)

Added start:watch command.
Minor change to start command (now runs only build:dev). start:extended now runs build.

This should speed up development process.

I thought about switching build:legacy to esbuild too, however esbuild does not support lowering to es5 which is needed to support IE users (~1.3% of desktop browser users use IE according to statcounter).

[bhousel]

We already have this working in the RapiD repo, even using the esbuild-plugin-babel to generate a legacy build for the tests and IE11.

I'd prefer to just send you a PR with the build tooling that we have to keep the projects more closely in sync.

[mbrzakovic]

We already have this working in the RapiD repo, even using the esbuild-plugin-babel to generate a legacy build for the tests and IE11.

I'd prefer to just send you a PR with the build tooling that we have to keep the projects more closely in sync.

That sounds great,
Please double check if the legacy build is working - Currently I am unable to https://mapwith.ai/rapid via IE11.
I'd prefer to keep the projects in sync as well, so lets work towards a correct common solution.

[bhousel]

OK, so I spent some time on this today and the IE11 story is not great. Here's a brain dump of what I learned today.

• @babel/polyfill has been deprecated a while ago in favor of just importing core-js at the main entry point of the application.

• I did try this, but had no luck getting Babel / esbuild to actually create a bundle that would work in IE11. I did try a lot of different options with @babel/preset-env useBuiltIns, also updated all our dependencies.

• The PhantomJS tests do continue to work (I consider this even more important than IE11), but that's because I've been including a core-js-bundle in a script tag in the test runner page.
  https://github.com/facebookincubator/RapiD/blob/08aead986ab7f1a39af3405ed5d9a50f1aa7b53e/test/index.html#L24

• I can also remove core-js from the iD bundle and use this same script tag trick early in the index.html page (before iD gets loaded), in this case IE11 will actually work:

    <script src='https://cdn.jsdelivr.net/npm/core-js-bundle@3.19/index.min.js'></script>

• But as you can see - nobody has looked at this in a while and there are all kinds of bugs in styling. Pointer Events like zoom and pan are not really working right anymore either. I guess it works, but really people shouldn't be using this.

I really can't spend any more time fighting with babel / core-js / esbuild to make iD work in IE11, let alone fixing all those other bugs once we get it working, so I'm going to just drop support on the RapiD side. It's probably been broken for a while and nobody noticed until you mentioned it on this PR yesterday. 😅

cc @Bonkles

[mbrzakovic]

@bhousel thanks for going this far on the IE11 story, your information is a great learning!
I've just double checked the current dev mirror via IE11 and I am confirming that map editting is possible however the user experience is bad - inconsistent ui elements, unexpected pointer events etc.
It seems to me that by continuing to support IE there is additional maintanence burden (mostly with build/bundle infrastructure and unit testing).
It is unfortunate that iD does not have usage telemetry that would provide more insight into the browser % usage statistics.

I think similarly as you did on rapiD side, decision should be made if iD should continue to support IE11.
I encourage everyone to please raise their opinions in the comments.

For this PR, based on the decision there are essentially two ways to processed:

1. Switch dev to esbuild, keep rollup for legacy
2. Switch to esbuild, drop legacy

In any case, as mentioned, I would prefer to reduce the code difference between the projects (iD, rapiD) which is why it is a good idea to merge all reasonable changes which we discussed in #8776

[kymckay]

I vote to drop IE11, have had my suspicions for a while that it is relevant to very very few (double digit at most) users of iD and the fact that nobody has complained seems to confirm that. A shame we don't have hard proof via telemetry like you say.

Edit: Even Microsoft are dropping support for it. Office 365 already doesn't since August, and the browser itself will be retired next year.

[bhousel]

For this PR, based on the decision there are essentially two ways to processed:

1. Switch dev to esbuild, keep rollup for legacy
2. Switch to esbuild, drop legacy

I think a third option, which takes things as far as I got last Friday, is worth considering as it cost no extra time to set up:

• in id.js and elsewhere - remove core-js (because this polyfill pack is the thing that is hard for esbuild/babel to deal with)
• in index.html - inject a core-js-bundle script if IE11 detected (prior to injecting iD.legacy.js)
• then we really can just use esbuild and drop rollup (it really is about 100x faster, and I do think this is worth doing).

But, this is really for - if people think supporting IE11 in some form is worth it, and knowing that there are more bugs to squash once we actually get it working. (my concern is more time than anything)

[tyrasd]

A shame we don't have hard proof via telemetry

Maybe @tomhughes has some means (by looking into the server logs) to see approximately how large the fraction of requests is which open the iD editor on osm.org?

[tomhughes]

There were 5904 editor start events yesterday (that's anybody using the edit button on the site but most will be iD) and 7 of them were using IE by the looks of it.

[tomhughes]

Top 25 browsers starting an editor yesterday:

[tyrasd]

I think similarly as you did on rapiD side, decision should be made if iD should continue to support IE11.

Sorry for delaying the decision on this for so long. My opinion is that we should drop support IE11. This is because of the relatively large to be expected amount of dev work needed to get it into an actually acceptably usable state, and the benefit of a more streamlined dev setup.

Switch to esbuild, drop legacy

This is the way I would go forward.

@mbrzakovic would you be able to finish up this pr (with #8776)? Before that, I would merge #8764, which was also kind of blocked on the decision of dropping IE11 support or not. For any further follow-up tasks: see #8811

[mbrzakovic]

@mbrzakovic would you be able to finish up this pr (with #8776)? After that, I would immediately merge #8764, which was also kind of blocked on the decision of dropping IE11 support or not.

Yea I can wrap it up, although please note that my dev bandwidth is very limited this and next week so I might not be super responsive on this topic during the time. Sounds like a good plan.

The idea was to first merge #8776 here, iron out few small items and then finally merge this PR.

Currently #8776 has few additional changes that support .legacy build which should be reverted now to be inline with the above-mentioned decision.
@bhousel do you have time to polish #8776?

[tyrasd]

Perfect, thanks 👍 And no worries. If we can land this sometime before mid January, it would be just fine for the 2.21 release.