Source/exports structure #211
Description
This issue is concerned with
- how src folders are organized
- how exports are defined for the end user
(they are related to an extent)
First off, I have never used the webpack aliases - and never will. Its too much of a leap of faith for me to blindly import things with magic names just for the sake of nicer looking imports. I'd rather have an understanding of the underlying source structure and use that, or ideally, the source is organized in a way that makes obvious sense for newcomers, or its easy to import from module directly. Currently the general structure is:
├── compact.js
├── components
│ ├── cameras
│ │ ├── CubeCamera.js
│ │ ├── OrthographicCamera.js
│ │ ├── PerspectiveCamera.js
│ │ └── index.js
│ ├── lights
│ │ ├── AmbientLight.js
│ │ ├── AreaLight.js
│ │ ├── DirectionalLight.js
│ │ ├── HemisphereLight.js
│ │ ├── PointLight.js
│ │ ├── SpotLight.js
│ │ └── index.js
│ └── meshes
│ ├── Box.js
│ ├── Cylinder.js
│ ├── Dodecahedron.js
│ ├── Extrude.js
│ ├── Group.js
│ ├── Icosahedron.js
│ ├── Lathe.js
│ ├── Line.js
│ ├── Model.js
│ ├── Octahedron.js
│ ├── Parametric.js
│ ├── Plane.js
│ ├── Polyhedron.js
│ ├── Ring.js
│ ├── Shape.js
│ ├── Sphere.js
│ ├── Tetrahedron.js
│ ├── Text.js
│ ├── Torus.js
│ ├── Torusknot.js
│ ├── Tube.js
│ └── index.js
├── core
│ ├── App.js
│ ├── CameraComponent.js
│ ├── Component.js
│ ├── LightComponent.js
│ ├── Loop.js
│ ├── MeshComponent.js
│ ├── ModuleManager.js
│ ├── ModuleSystem.js
│ ├── PointsComponent.js
│ ├── errors.js
│ ├── index.js
│ └── prototype
│ └── attributes.js
├── deprecation.js
├── extras
│ ├── index.js
│ ├── pass
│ │ ├── ClearPass.js
│ │ ├── MaskPass.js
│ │ ├── Pass.js
│ │ ├── RenderPass.js
│ │ ├── ShaderPass.js
│ │ ├── TexturePass.js
│ │ └── index.js
│ └── shader
│ ├── CopyShader.js
│ └── index.js
├── index.js
├── modules
│ ├── app
│ │ ├── CameraModule.js
│ │ ├── ElementModule.js
│ │ ├── EventsPatchModule.js
│ │ ├── PostProcessorModule.js
│ │ ├── RenderingModule.js
│ │ ├── ResizeModule.js
│ │ ├── SceneModule.js
│ │ ├── VirtualMouseModule.js
│ │ ├── compact.js
│ │ ├── export.js
│ │ └── index.js
│ ├── controls
│ │ ├── OrbitModule.js
│ │ ├── export.js
│ │ ├── index.js
│ │ └── lib
│ │ └── ThreeOrbitControls.js
│ ├── mesh
│ │ ├── DynamicGeometryModule.js
│ │ ├── TextureModule.js
│ │ ├── export.js
│ │ └── index.js
│ └── presets
│ ├── Preset.js
│ ├── app
│ │ └── basic.js
│ └── index.js
├── polyfill.js
└── utils
├── extend.js
├── index.js
└── transformData.js
@sasha240100 what is reason for export.js files, if index.js ones are already doing the whole export * from './thingy.js' dance?
I don't think hiding project structure behind webpack aliases is the greatest solution. For one, that will be tricky to maintain, and it's confusing to beginners.
One approach could be to have a main index file which exports everything. Perhaps with named suffixes/prefixes, then it might look like: (similar to what currently it is like, with exceptions for controls, app).
// This works
import { App } from 'whs'
// This does not
import { SceneModule } from 'whs'
// this does
import { app as AppModules } from 'whs'
const { SceneModule } = AppModules
// This does not
import { OrbitModule } from 'whs'
// This does
import { controls as ControlsModules } from 'whs'
const { OrbitModule } = ControlsModules
// This does
import { Box } from 'whs'I think I would like it if every single thing could be imported directly from the module.
Just want to get this discussion started, I think the way we export items can be improved (consistency), hopefully we can all agree on something.
Considerations as to how this is maintained with respect to docs as well.
Furthermore, we should be careful to make sure we are not breaking spec the way we use ES6 modules. Babel follows the spec for the syntax, but the actual module resolution spec is different (and webpack 2 does not strictly follow it). And in node, you will need .jsm to be able to use ES6 modules (when the hit node). It would be super neat to use full ES6 in node with no transpiling for headless-gl - for the most part, it is just import/export syntax preventing the codebase running in Node 6.
Version:
- v2.x.x
- v1.x.x
Issue type:
- Bug
- Proposal/Enhancement
- Question
Tested on:
Desktop
- Chrome
- Chrome Canary
- Chrome dev-channel
- Firefox
- Opera
- Microsoft IE
- Microsoft Edge
Android
- Chrome
- Firefox
- Opera
IOS
- Chrome
- Firefox
- Opera