4 ms·
> There's also ... [...] (I assume you meant to write your example in CommonJS style, because that's not valid a ES6 export, they must be top-level). Doesn't
by allover 10y ago
> There's also ... [...]
(I assume you meant to write your example in CommonJS style, because that's not valid a ES6 export, they must be top-level).
Doesn't your example highlight exactly why even executing the code wouldn't even help you there?
- z3t4 10y agoDidn't know you could only export at the global scope. Wanted to show that you could do stupid, hard to analyze things in ES6 modules too. But maybe you can't !? Although I don't want a committee to not only decide what is stupid or not, but also hard code it into the spec so I can't do some things even if I have very good reasons to. Like being able to require modules locally to make the code easier to reason about, and easier to delete, copy, share, reuse and manage. It's what made NodeJS so popular, because it's so easy to use, reuse and share modules.
- bakkoting 10y ago> Wanted to show that you could do stupid, hard to analyze things in ES6 modules too. But maybe you can't !? You can't, at least not in this way. A module's imported and exported names are statically determined. Of course, you can just export a single object, and then make that object arbitrarily complex depending on runtime behavior. > Like being able to require modules locally Not sure what this means.
- z3t4 10y agolocally: inside functions