Recommend separating Engine, View framework, and components. Packaging thoughts.

[chickendinosaur]

I notice you have View as well as things Layouts all bundled up.

The current structure of the source makes it tougher using webpack/browserify since you don't provide the source in the dist folder where the "main" property points of the npm package. It's nice to have a standalone version for people to drag and drop but you can leave that in the dist folder with the source. If I wanted to do a require('samsarajs/dom/Surface') so I don't bundle up things I don't want using a tool like webpack or browserify I would have to go up a level using '.../' which is something you don't want to see.

I'm pretty sure the best thing you could do is run a regex to convert all of your amd statements to es6 import/export and use the babel-umd transform with destination pointed to /dist so all of the source is packaged in the dist folder and people can choose what they want to use in a fluent manner. Also, I think providing the source files in npm module download right now may be a good thing since webpack 2.0 treeshaking will require the es6 import statements but you would still want to have a umd version for others that aren't there yet. Welcome to why the JavaScript ecosystem is so confusing for new comers right?

People like myself will design other/more manageable way to do a "View" for encapsulating nodes and expressing the render tree. The things we're after here is the core functionality for motion performance using DOM.

I know some of this has been mentioned but this was more for information purposes in case you didn't see the use cases a lot are doing and for others thinking the same thing. Let me know if you need help although I'm currently swamped with real life but I'll do what I can.

[dmvaldman]

Yeah, the current /dist folder only has the bundled files as you mention, and there is no CommonJS format for each individual source file. This is an artifact of how I currently develop the library, which is just to use the AMD files in the /samsara directory. When we move to an es6 format this will no longer be the case, and you'll be able to import individual files and do tree shaking.

[trusktr]

@dmvaldman The only thing you have to do to support this is to simply publish the the /samsara folder to NPM too.

Any modern bundler like Webpack, JSPM, Browserify, understands AMD format.

---

@chickendinosaur, after @dmvaldman makes that small change, you can just import the specific files that you want after making an alias to the /samsara folder.

In Webpack, the resolve.alias property can be used to define an alias like samsara: samsara/samsara' (which means "let anything imported from samsara/ actually beimported from samsara/samsara") then things can be imported like

import RenderNode from 'samsara/core/nodes/RenderTreeNode'

Without the alias it would still work, but the import would need to be

import RenderNode from 'samsara/samsara/core/nodes/RenderTreeNode'

Some libs put stuff in src, so the alias in that case would be some-lib: some-lib/src' in order to avoid having to put src/ in every import path.

[trusktr]

@dmvaldman @chickendinosaur Oops, I was looking at https://www.npmjs.com/package/samsara, not https://www.npmjs.com/package/samsarajs.

samsarajs on NPM already includes the /samsara folder, so you're good to go!

@chickendinosaur You can import any file just as they are, right now, in Webpack. They don't need to be in ES6 format.

In AMD format there may not be tree shaking by Webpack, though it is not strictly impossible because there's nothing inherent about AMD that prevents a bundler from statically analyzing functions to see which are used or not, but, at least you can import stuff.

[trusktr]

@dmvaldman You can possibly close this one, since the files are importable already with standard bundlers, and prefer #18 in case you want to migrate to that format in the future. (Safari tech preview already has ES6 module loader, so it can load ES6 modules at runtime without any build tools!)