Allow a switch to disable building of the legacy bundle #333
Comments
|
Would you be satisfied with a command-line flag like |
|
Definitely! ===== Although I do still believe that it is a bit 'backwards' to 'burden' all developers with this additional cost. Let's say 50% of projects require support for these legacy browsers. In the unlikely event of the legacy bundle producing an error during the build process, 50% of the people will care, whereas another 50% would not. Out of those 50%, let's say 10% locally test their code on old browsers for every change. In the even more unlikely event that the legacy bundle produces code which behaves differently from the modern bundle, only 5% of total Meteor users would get a chance to notice this. It seems more reasonable to me to accommodate these users with a flag to enable legacy builds, rather than to ask all the others to disable it. Actually, when thinking about it, I think you already do this right now using the --production switch (which performs production bundling, rather than development bundling). I think we can assume all developers make use of a modern browser, so it doesn't seem logical to bundle legacy code for a development build (the --production flag indicates that a meteor run, without --production, creates a development build). When users want to pick up errors for legacy builds before releasing, they should probably configure their CI or local tests to use the --production flag. Hence I really do believe the default behavior should be to not build the legacy bundle, but I'm more than happy to configure our development scripts to apply a --no-legacy option! |
|
While I do agree that the majority of cases do not need to support legacy browsers, that policy does not fit in with Meteor's level of backwards compatibility. The only way the default will switch to only supporting modern browsers is if / when Meteor switches to 2.0 and can declare breaking API changes. Until then When |
|
@KoenLav Next to backward compatibility now, it's also important for backwards compatibility in the future. Because legacy is a moving target (currently roughly browsers that support async/await). And because not all browsers are auto-updating, you may want to support legacy browsers some day in the future (e.g. a 2 year old safari browser). So in order not to break when the definition of legacy shifts due to some ES20xx features, it's better to have it enabled by default. It's easy enough to make an alias / npm script / whatever that inlcudes --no-legacy |
|
Another idea is to control it via a package like That would be useful for folks that don't need legacy at all. |
|
@coagmano there's already a file for that ( |
|
@sebakerckhof Just tried it out and no combination of browser, browser.legacy, or browser.modern (all with and without web. prefix) made any difference. Though using the platform commands does make more sense than a package for totally disabling a legacy bundle I do think that |
|
"But I think a very common use case is to develop constantly on modern browsers and only once in a while check a legacy one. So the --no-legacy option seems to be the best to me." This vouches for only building the legacy bundle when using the production switch, actually. "And because not all browsers are auto-updating, you may want to support legacy browsers some day in the future (e.g. a 2 year old safari browser)." Good point, but still, this feels backwards. Because some vendors decide to not move ahead their installed base we are held to support browsers which we can pretty much consider to be broken? I think the responsibility in that regard has already switched to the vendor, rather than the developer. In addition to that this still vouches for only building the legacy bundle when building for production, and displaying a warning when a legacy browser is used in development, as we can expect developers to move ahead with time. |
|
While delaying the legacy build limits the effect of the issue, it doesn't mitigate it completely; because a core will still be maxed out while making changes to the code, and this causes the server process to take more time to respond to new changes. Even when we would make the legacy build cancellable (while we're at it we might as well make both builds cancellable), it still has some impact. As we don't need this impact, I'd like to mitigate it all together. @benjamn I think a switch would be a nice starting point, but I would definitely like to ask you to consider only building legacy when the production switch is applied, as I think only a handful of developers will check the legacy bundle (ever, when they are not debugging for it specifically). |
|
@coagmano . I didn't mean it works like that today. I meant there's already a place to say which platforms you want to target (e.g.
Yeah, but if I then need to debug a problem with the legacy bundle, I each time have to wait for the extremely slow minification and so on to take place during development and I think I loose sourcemaps as well. I could disable that. But that's more work than adding Furthermore, while Meteor is zero-config, there's still a lot of new concepts to learn for new users. To make onboarding as easy as possible I think it should support as many browses as it can out of the box. This optimization of rebuild speeds will only make sense once your applicaiton has grown and by then you may have learnt about the
True, but unfortunately your users won't see it that way. For them it's your application that's broken. And for a lot of us these decisions are not made by the developers but by some product manager. Saying "It's the browsers fault" is an answer my customers generally don't accept. And on iOS there's not even an alternative to safari... (since chrome is also just safari) |
|
@sebakerckhof --no-legacy it is! |
|
--no-legacy would be perfect. It's a shame that right now half of the rebuild time is being spent for legacy browsers which we don't support in our project. |
|
--no-legacy would be a preferred option for myself. If it was simple enough to achieve then adding options to disable all forms of builds would probably be useful for testing in specific environments e.g I'd also include the builds for IOS and android but I don't know what they are called as I do not use them. I can just about see me using a --no-modern option for when I was specifically targeting testing in a legacy browser. |
|
Before this can be done, could qualialabs package do the job ? |
|
@sabativi I had a look at the qualialobs:one package today and it does do what I need it to do. Thanks very much for the pointer as I have not come across any mention of this package before. For people who have not tried it, this gives control of if you only want to compile the modern or the legacy package via an environment variable. It does what I need meteor to do. The only drawback to the package is that it needs to be git cloned to a local package for it to work. I'm not sure if it would need to be updated when meteor updates (possibly not as it is quite small). If there was some way to make this package into a meteor pull request with command line options instead of env variables it would be most appreciated by myself. Up until then, I'll continue to use the qualialabs package. |
|
Another use case for this: |
|
Any update on this? None of our projects support legacy browsers anyway, would be awesome to remove this overhead. |
|
Also pinging, this would be nice to cut away from. |
|
We would also like this, but even further - could we disable both client bundles as well? We have several people focused on back-end and Apollo schemas, and frequently they just need the server process running, so they can test via the playground. |
|
This is related to the issue being discussed, that sometimes you want to make sure you have legacy compatibility. A while ago I had an issue with the legacy browser requirements changing, and Chrome 63 on the iPad mini no longer loading meteor apps. (it started randomly, was fixed randomly, and at some point again randomly started breaking again). I had to re-implement the fix linked in the issue above. To be honest if the legacy/modern browser compatibility bundles is going to randomly break older browsers, then I'd rather only use the legacy build, because who knows which older browsers, and when, they'll be broken. |
This commit implements an --exclude-archs arg to the run command which allows you to pass a comma-seperated list of architectures to exclude. Motivation: Improve rebuild speeds, by allowing to leave out certain web architectures during development. Meteor rebuild speeds, although greatly improved in recent versions, is still a common point of frustration as seen in the issues (meteor#10800) and on the forum (https://forums.meteor.com/t/2x-to-3x-longer-build-time-also-on-testing-since-1-8-2-update/51028/3) One reason for slow rebuilds is high memory pressure (meteor#9568). The web.browser.legacy architecture is currently always being build while most of us will only test this every once in a while. So while we don't need it most of times during development it does add to the high memory usage. Furthermore, even though these builds are delayed, long-running synchronous tasks have the potential to block the server startup (meteor#10261). This last issue can be partially, but not fully, improved by meteor#10427 Therefore a commonly requested feature has been to disable the legacy build (meteor/meteor-feature-requests#333) However, we may also temporarily disable cordova builds and we may even want to disable just the web.browser build if we're just debugging a bug in the legacy build. Therefore I chose to create the more generic --exclude-archs option.
I don't understand why this isn't offered yet. It is scary to imagine trying to calculate how many hours of waiting happen every day and how many useless CPU cycles wasted, if we summed up all of us developers and all our changes... @benjamn is this planned yet, or did you not manage to find a conceptual solution that you are comfortable with? |
|
@gotjoshua There is a PR for this now: meteor/meteor#10824 |
|
awesome~ |
This commit implements an --exclude-archs arg to the run command which allows you to pass a comma-seperated list of architectures to exclude. Motivation: Improve rebuild speeds, by allowing to leave out certain web architectures during development. Meteor rebuild speeds, although greatly improved in recent versions, is still a common point of frustration as seen in the issues (meteor#10800) and on the forum (https://forums.meteor.com/t/2x-to-3x-longer-build-time-also-on-testing-since-1-8-2-update/51028/3) One reason for slow rebuilds is high memory pressure (meteor#9568). The web.browser.legacy architecture is currently always being build while most of us will only test this every once in a while. So while we don't need it most of times during development it does add to the high memory usage. Furthermore, even though these builds are delayed, long-running synchronous tasks have the potential to block the server startup (meteor#10261). This last issue can be partially, but not fully, improved by meteor#10427 Therefore a commonly requested feature has been to disable the legacy build (meteor/meteor-feature-requests#333) However, we may also temporarily disable cordova builds and we may even want to disable just the web.browser build if we're just debugging a bug in the legacy build. Therefore I chose to create the more generic --exclude-archs option.
|
Shouldn't this be closed now, we have: Cheers for implementing this. I came across this issue after googling how to do this. |
|
I think so. I believe there is another discussion about enabling it for the |
If the project needs to support legacy browsers (which is already a subset of projects) there are only two scenarios in which this work would be useful:
In short what we have to consider is; is it worth to impose the burden of double compilation on all developers, for the eventuality of some edge cases occurring in legacy compilation, whereas even when these edge cases occur they are only relevant for a subset of projects.
In my opinion the answer to that question, by default, should be no.
I can however imagine with different project experience you might answer yes to this question, but in my opinion at least the option to disable this should be provided.
The text was updated successfully, but these errors were encountered: