Material-ui: [Core] Folder structure proposal

Created on 12 Mar 2016  ·  12Comments  ·  Source: mui-org/material-ui

After having a good discussion with @mbrookes we came up with this proposal on how we should structure our folders to make imports easier and to express what's internal and what's not:

src/
  - internal/
    - styles/
      - transformers/...
    - InkBar.jsx
    - EnhancedButton.jsx
    - ...
  - TextField/...
  - GridList/...
  - Toolbar/...
  - ToolbarTitle/...
  - getMuiTheme/...
  - colors.js
  - index.js
  - MuiThemeProvider.jsx
  - muiThemeable.jsx
  - ...

Some notes:

  1. No more styles and utils under the src folder!
  2. Everything internal with any structure will go in the internal folder
  3. Everything public will go in the src folder with flat structure
  4. Utility modules will be files under the src folder
  5. Components will have their own folder under the src folder
  6. All internal shared components will go under the src/internal folder

This will help us easily write publish script to put everything under the root folder before publishing.
And the end result will have absolutely flat structure, helps users do this:

import {cyan500} from 'material-ui/colors';
import TextField from 'material-ui/TextField';
import TextField from 'material-ui/TextField/stateless';
import MuiThemeProvider from 'material-ui/MuiThemeProvider';
import muiThemeable from 'material-ui/muiThemeable';

Ain't that beautiful? @callemall/material-ui? :heart_eyes:

discussion

Most helpful comment

I'm fine without /src. Recompose uses a base /src/packages folder, React uses a base /packages folder. I say we pick the best of both and whatever makes sense for us :smile:

All 12 comments

I really like this idea.
Regarding the publish script and the folder organization for the releases. What do you think about having everything under a packages folder?
That would looks like:

    packages/
      ├── material-ui/
      |  ├── TextField/
      |  ├── Toolbar/
      |  ├── ...
      ├── eslint-plugin-material-ui/
      |  └── ...
      └── material-ui-native/
         └── ...

even the docs site :+1: I really like this :+1: :+1: :heart_eyes:

@oliviertassinari I think that's a great idea!

@alitaheri Thanks, this is looking awesome :+1:

Let me know if you need any hand with a publish script etc

@oliviertassinari I must be missing something here. What do we get by nesting everything under packages that we don't already get with everything nested under /?

    /
      ├── material-ui/
      |  ├── TextField/
      |  ├── Toolbar/
      |  ├── ...
      ├── eslint-plugin-material-ui/
      |  └── ...
      └── material-ui-native/
         └── ...

(Other than renaming src to material-ui...)

What do we get by nesting everything under packages

Aside from being more coherent with React and Babel, we get that people can expect everything inside the packages folder to be an npm package.
So I think that it's cleaner and more intuitive.
I don't think that we will have as many folders as Babel, but how knows?

What do you think about having everything under a packages folder?

Yeah this is what I had in mind too :+1:: https://github.com/newoga/material-ui/tree/monorepo-directories/src/packages/material-ui

I would even consider not having the /internal folder but have something like a material-ui-internal or material-ui-utils package in the packages folder. It'd be better if people didn't even have access to those files/components when they were importing from 'material-ui' :wink:

I think we can borrow the project structure and scripts pretty heavily from recompose, I think it does a pretty good job setting this up.

: https://github.com/newoga/material-ui/tree/monorepo-directories/src/packages/material-ui

Without /src though, right?

/packages/material-ui replaces /src...

I'm fine without /src. Recompose uses a base /src/packages folder, React uses a base /packages folder. I say we pick the best of both and whatever makes sense for us :smile:

Going back to the original proposed structure, where do the base themes go? Not internal/styles/baseThemes that's for sure!

/themes?

(and presumably getMuiTheme also goes in root?).

@mbrookes The lightBaseTheme doesn't really need to be external as it's the default, how about just putting the dark on the root, and the lightBaseTheme... well we shove it in getMuiTheme :laughing:

I was also thinking, there is no need to have spacing, zIndex, typography files while we can just put them inside the getMuiTheme!

(and presumably getMuiTheme also goes in root?).

true

@oliviertassinari Sorry, I had closed in favour of #2679, but you're right, this is a subset of that issue.

Was this page helpful?
0 / 5 - 0 ratings