If you use Ember or have used it in the past, what would it take for you to feel great about using it for your next new project (and recommending it to your friends for new projects)? Feel free to say "I'd already use it" but be honest :)
-
-
2: Some questions: - how to deal with browser/module/main/etc entry points (which should win, what should its semantics be) - is it ok for CJS modules to export just a default export with its exports as a data bag?
-
3: - for CJS, what kind of tree shaking is required (or is it ok to pull in the entire package) - how acceptable is it to end up with a lot of package duplicates? Is it tolerable? Would it be important to at least provide a warning? Does yarn --flat work?
-
4: I think people have a sense that we could just do what browserify would have done, which is definitely possible. I'd feel much better about it if someone wrote up an RFC at least exploring these questions.
-
5/5: fwiw, almost the entirety of why wrapper packages are needed in Ember today is because there is no persistent, long-lived defacto standard about these questions. We could live with whatever, I think, if we at least explored the questions and had answers.
-
(I hope this doesn't come off as dismissive or stalling; I'm hoping to unlock some effort by writing down what thorny issues have made this hard to do historically)
-
Oh, and if the answer to any of the above is configuration: - let's design the config - we'd need to deal with how dependencies are supposed to deal with their own dependencies.
-
I'd also take near-term incremental improvement ideas.
- 13 more replies
New conversation -
-
-
Unless this is way more commonly understood than I realize, I feel like it’d be helpful to get some idea of why this is so hard in Ember to begin with when webpack + not that much config lets you import all the things
-
And I don’t mean “plz tell me why Ember is deficient” because obv I’m not of that opinion, but I def am not clear on all the historical reasons that make “import things from node_modules like everyone else can” such a big thing to tackle
-
So I imagine some context might help to level-set expectations regarding what’s possible in the near and mid-term, and also to make non-core RFC authorship on this topic an easier thing to contribute to
-
So while I do want this, the trouble is not knowing if - package is already minified or otherwise built in a way that would exclude it from certain build operations - package needs transpiled (and req features if so) - module format Webpack doesn't really solve this at all.
-
I actually didn't mean to imply it's such a big thing. I was hoping that laying out the questions would make it seem more tractable. Other systems have answers to these questions, but often they're implementation details that drift over time.
-
Since Ember tries for better compatibility than that over more time, we just need to solidify some answers to these questions that we can keep working (and do the usual ember migration story if circumstances cause us to want to change the answers)
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.