.type for module type

[jonathanong]

cjs, rjs, es6, global, web_components, etc.

https://github.com/component/component/issues/476

[ianstormtaylor]

im curious to know why this is needed. the way i see is rjs and global are both not something we want to support anyways, and es6 will involve a lot more work so we might as well wait until they are solidified and figure out what will be needed then

[jonathanong]

the way i see is rjs and global are both not something we want to support anyways

yeah i just added it to the list for possible values just to open a discussion. they are hopefully going away with es6.

es6 will involve a lot more work so we might as well wait until they are solidified and figure out what will be needed then

maybe. i've been looking into es6, and it seems like we should be able to just treat from "module" like require calls and do module "name" {} as the require.register('name', function (exports, module) {} stuff.

this of course assumes you just do module emitter from "component/emitter"; instead of doing module emitter from "https://github.com/component/emitter/1.0.0/index.js" (god i hope people don't do that, though that's kind of the point of es6 - remove the need for package managers).

[ianstormtaylor]

that sounds cool for es6. i'm down to have the rjs and global stuff in the list purely for thinking if it makes sense to abstract the type, but if they present any actual problem to a nicer implementation i'd want to remove them right away

[dshimkoski]

i currently have to deal with some legacy/third party code that would be a chore to wrap up in modules - just to re-expose in the global scope anyway - hence the suggestion for global, which could also be used to upgrade the environment with shims, etc.

i'd prefer to include JSON, array shims, etc., up front, rather than rig up fallbacks in a bunch of cjs modules. the code is going into the bundle either way, so i'd rather write Array.isArray in all of my modules without having to worry about requiring a shim first.

i'm currently using global scripts in "boot" modules only, all other components are cjs.

i suppose the danger of putting it in the spec would be that people start including global scripts outside of the root level. for instance, A and B require feature X, so they write their own global polyfills. C requires both of these modules and gets two different implementations of X, possibly breaking A or B.

i think this is why @anthonyshort suggested having environment flags in the original thread... something like "canonical shims". component-builder could provide these so the community doesn't have to bother with them all the time.

in any case, after thinking it through, global gets a :-1: from me too.

as for the other use case, i.e., handling legacy/crufty third party code, i suppose that can be delegated to cat :)

[ianstormtaylor]

nice yeah, i agree with all of your thoughts there. i think the new builder api should make this real easy, anything can just be cat'd on to the front of the build

[jonathanong]

okay my opinion right now is that we should only support CJS and ES6 modules. it should be easy to infer the type with something like http://github.com/yahoo/js-module-formats in the builder. for now, it'll compile down to CJS.

in the future, we should compile to ES6 modules somehow, but that's like half a decade away.

thus, i don't think type is necessary. don't really want to support globals. easier just to use script tags or something.

[ianstormtaylor]

+1