Principles for guiding v4 discussion

[robpaveza]

Hello folks,

I'd like to suggest that we make a discussion around the question: how do we decide what to do or not do for the Source Maps v4 proposal?*

I'd like to propose the following principles:

• Requires the minimum number of tools to update. The JavaScript ecosystem is tremendously huge, and potential customers might encounter friction if they need to do a major-version bump of a build tool. If possible, we should keep the update scoped in such a way that customers could leverage plugins (or something similar) to take advantage of the maximum amount of functionality.
• Supports future evolution without making huge, industry-moving changes. It would be nice if we didn't have to coordinate everybody in the ecosystem at once to make incremental improvements. The change should be opinionated enough to be able to allow future changes where it's easy enough for, at least, additional fields can be added and progressed with build system plugins
• Size footprint: Source maps are commonly downloaded over the network, and features should be balanced against bandwidth costs

What other principles should we apply in making this decision, and how do you think we should weight them?

Let's collate this information in this thread, and we can come back to the main thread with better decisions about how we approach introducing features in the update.

[jkrems]

I think it would be worthwhile to have ordered principles since realistically we will have to pick trade-offs between them. Weighing them beyond some kind of order feels overly precise to me (illusion of precision).

With that in mind, I believe that "Size footprint" should likely move to spot (1) or (2). To me it goes beyond the network/IO impact, a bigger source map also affects resource usage in build systems (more data to parse and serialize).

[robpaveza]

Clearly, the principles will (at the end) need to be ordered. But I'd like to ask for people to list principles that they find to be important here.

With respect to size footprint, clearly there's always going to be a direct trade-off between the that and "functionality", for some definition of the latter. My personal opinion is that we shouldn't try to boil the ocean, but if we have tons of tool makers who want to ensure we have the smallest possible output, I'll withdraw.

[brad4d]

It seems that no one has come up with additional principles to add.

I would definitely second @jkrems recommendation that size footprint should be top priority.
I know it will definitely be the top priority for closure-compiler.