I worry that any means of forcing an automatic ordering will eventually fail. (In fact this kind of string deduplication is a very limited case of that.) Problems with other ideas So it's an optional dependency.Ĭommon sub-expression elimination is probably a similar case: you have to pick the shortest possible non-colliding temporary variable names. The plugin never makes the uncompressed script longer, so it doesn't really matter if it runs before or after the local mangler, but it's better if it does run first. Then as long as it's run first, the local name mangler later does the job of picking even shorter names that don't collide with anything else. So what it does instead is generate relatively safe names like const _1 = "a long string". This duplicates the work of the local name mangler. My experimental string literal minifying plugin, although probably not useful in practice, demonstrates one interesting problem: it has to choose the shortest non-colliding local variable names possible. It's probably also worth mentioning optional orderings. This is a nice solution especially since only one plugin handles collision avoidance rather than both having to solve that, but again depends on ordering: the property mangler must run first. Instead I opted for a much simpler solution: the local mangler already makes sure it doesn't collide with global names, so as long as the property mangler runs first, the local mangler does the work of ensuring none of the names it chooses collides with anything. Doing this would require even further rearchitecting of Babel, which I don't think is reasonable. This becomes extremely thorny when you process multiple script files, since you can't pick a global property name until you've seen all future scripts and know what local names will be used across all of them. So the property mangler and local mangler have to co-operate to ensure they do not pick colliding names. I've written delta-modeling libraries for LaTeX and JavaScript).Ĭonsole.log(a + a) // oops: does not use global variable (PS: This proposal is loosely based on delta modeling, the topic of my PhD thesis. It is a rather radical departure from the status quo (although I believe it can be made fully backwards compatible for users). If you don't think this idea will fly, fair enough. There are undoubtedly ways in which this proposal can still be improved, but I think I've made the general idea clear. Perhaps a partially ordered set of related concepts could be released as package (which I'll call a scaffolding), and plugins could import it to order themselves relative to it. On the other hand, if babel was aware of them, it could give better feedback.
On the one hand, we could allow unrestricted use of them, and the community would probably converge on a common set. I'm ambivalent on whether or not these concepts should need to be registered or declared somewhere. If they properly order their own plugin relative to those concepts, they don't have to be aware of each other specifically.Īs for the concepts themselves, I guess babel would have to enforce some naming convention or other, and here I've assumed that their names have to be enclosed by parentheses. In these examples, we assume that the plugin authors are all aware of the (flow-types-exist) and (flow-types-do-not-exist) concepts.
Simpler example: if you specify a plugin only modifies ES2015 classes and you make that run after the plugin that transforms classes, then it won't run at all because at that point the classes will have been transformed into a function already. User's shouldn't have to change their config to make it compile correctly (or get a weird error message about how a plugin isn't enabled when it's just in the "wrong" order). The order that you specify plugins/presets in a config matters in Babel. Copying from babel/notes#19, many other issues linked there Issue
0 kommentar(er)
