-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recommend separating Engine, View framework, and components. Packaging thoughts. #36
Comments
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. |
@dmvaldman The only thing you have to do to support this is to simply publish the the 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 In Webpack, the 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 |
@dmvaldman @chickendinosaur Oops, I was looking at https://www.npmjs.com/package/samsara, not https://www.npmjs.com/package/samsarajs.
@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. |
@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!) |
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.
The text was updated successfully, but these errors were encountered: