Closed jonathanong closed 10 years ago
I think this is too opinionated for the spec, but it could be completely fine as a cli plugin. The way we bundle stuff is different so this wouldn't handle our use case. I think we'd need to experiment more as a community before know what should be standardized here. Separate component builds sounds like a better solution to me
naw not doing cli plugin. easier just to implement all the logic yourself in < 10 lines. this is just simplest case i can think of.
i don't expect it to handle all cases, but it should be simple enough for people to not complain that component can't bundle.
i haven't heard people complaining about that being our biggest issue. i'm very -1 including something in the spec just because it can be written in 10 lines, especially if its already not expected to handle all cases. if anything a 10 line plugin is exactly the kind of plugin i like..
It's an amd vs cjs issue, not component.
This isn't something for people like us who can JS API around everything, but a stepping stone to the JS api for new users once they want something more complicated than the cli.
Actually I'm -1 now for any bundling tool because of docs and support issues. Let's just hope people are smart enough to make a blog post or wiki on it or something.
easy with the resolver. i'm thinking of this:
Each bundle must be a
local
component. Bundles are defined in your component.json as:Although bundle names must be
local
components, you do not have to define them again inlocals
, but you still needpaths
. this would be annoying. in fact,bundles
should replacelocals
.The first bundle,
<boot>
will be assumed to be the "initial" bundle that includesrequire()
. There will also be a build calledcommon
that will include all the common dependencies/locals of all the non-boot bundles.Example:
will create the builds:
so visitors should only load
bundle-boot
. users would loadcommon
andbundle-user
. users on the settings page will additionally loadbundle-user-settings
.this is the simplest case i can think of, and it should handle 99% of cases. any other use-cases will require the user to use the JS API themselves.