[docs] Improve codesandbox generation logic

[oliviertassinari]

When using the export to codesandbox feature of the demos with the data grid, we get: https://codesandbox.io/s/quirky-galois-9kfv5?file=/demo.tsx. For instance, using https://deploy-preview-165--material-ui-x.netlify.app/components/autocomplete/#ComboBox.tsx. I think that we can simply include @material-ui/core, always in the list of dependency. It seems to be a simple default, with no significant downside.

Closes mui/mui-x#157

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 7631887

[eps1lon]

The existing logic considered peer dependencies which core seems to be. The lab has a peer on core and so should the grid.

While the new logic is a decent approximation I see no reason to approximate it if we already have existing accurate logic.

[oliviertassinari]

@eps1lon The motivation would be to edge for a known future, assuming we will have dozens of packages. Maintaining the list of peer dependencies could be overkill compared to the cost of overloading in codesandbox. It was already frustrating for @material-ui/x-grid and @material-ui/data-grid, what is it going to be later on? But I don't have a strong preference. I'm also happy to not anticipate, to see later.

updated

[eps1lon]

The point is that if the logic for peer dependencies is lacking then it's lacking for every package not just core. This is the sort of code we'll forgot about if we change the package structure and in line with "no abstraction is better then the wrong one".

It seems to me the existing logic isn't re-used because it might look "unclean" or includes "just copying code". Both these things are fine since they better reveal the underlying logic.