"src" for source code

[jonathanong]

since people love their CS, we should make it more general and have a src: folder instead of just files. it's an array for anything to be compiled.

{
  "src": [ "index.coffee" ],
  "scripts": [ "index.js" ]
}

[dominicbarnes]

tbh, I kinda like that various plugins have their own segments of the component.json. I don't think this is necessarilly something we need to include in core.

[ianstormtaylor]

i kind of like that all the stuff that compiles to js goes in scripts too. that's what extensions are for anyways? either way, src seems weird. should either be grouped by type or grouped by extension imo, not less structure

[dominicbarnes]

Yeah, src is really weird to me too. At the very least, nothing else is abbreviated in this fashion.

[jonathanong]

i don't want the builder to check whether the file is a Javascript file or not. i'd be okay if coffee stuff was in coffee or something (it doesn't have to be in the specs) as long as it isn't in scripts. of course, this isn't difficult to solve during the build.

i just have an aversion to publishing stuff that needs to be compile (except i use rework anyways). i don't want anything in the main component registry to be written in anything but vanilla JS and CSS.

[Swatinem]

i don't want anything in the main component registry to be written in anything but vanilla JS and CSS.

That was one of the original goals, ye. Compiling should be restricted to pre-publish makefiles or private components, just as we have now with templates.

[dominicbarnes]

@Swatinem you can include templates as raw HTML now, you don't need to pre-compile them anymore.

I tend to agree that published components should only be vanilla though. Perhaps plugins need to behave more like hooks and get run pre-publish, rather than needing to be integrated into the registry.

[Swatinem]

I do mean things like component-jade where .jade files get compiled to functions :-)

[jonathanong]

IMO templates should only be HTML unless they are private components. how do you guys feel about adding that to the spec?

see my comment in: https://github.com/component/spec/issues/31#issuecomment-31072699

i think that for public components, we should push any cs/jade files to source or something and have scripts only be JS files. for private components, it shouldn't matter since the builder should be able to handle it anyways.

[ianstormtaylor]

i dont think templates should need to be only HTML. or at least the thing i've also been using it for is markdown files.

i could be convinced that that need is only useful in private components, but i dont like the idea of having a separate restriction that applies only to private ones. its already unfortunate that we need the restriction on keeping coffee out of scripts from a simple abstration perspective. i think a verbal restriction, or "best practices" is fine, but i'd rather not have it be in the spec or throw an error or something in the registry

[jonathanong]

people don't read though. you have to throw errors otherwise people won't listen. specs are useless otherwise.

[Swatinem]

The problem I see is that component should not grow to be a giant piece of pulling in tons of dependencies. Having public components require coffee or jade or whatever to compile means those tools need to come with component itself, which is something that it just should not do. Restricting the usage of those to private components keeps component itself lean.

[yields]

The problem I see is that component should not grow to be a giant piece of pulling in tons of dependencies

+500 i really hope we won't end up with a bunch of WARN!!!! like npm has or too many rules.

[jonathanong]

haha. the problem with npm is the usability. most of the warns should be thrown on publish or something, not when you install (which is freaking stupid since consumers can't do shit about it). any errors should be thrown on component doctor or component publish, etc. any components that don't validate shouldn't be able to be added to the registry at all.

[jonathanong]

@Swatinem's logic makes a lot of sense. you should be able to consume any public component (at least in our registry) without any plugins or additional dependencies. otherwise, it's just bad usability.

[ianstormtaylor]

yeah i agree with not needing plugins. i just am not yet convinced that HTML is the only thing useful in templates. i could see someone writing .txt file templates if they wanted. its not as cut-and-dry as JS or CSS because the only real requirement for a template is that its a string.. whereas JS has to be able to compile when concated together with the other js files

would rather have a simpler system whenever possible than to have exceptions for everything little thing

[jonathanong]

@ianstormtaylor yeah, i don't think we should be strict with HTML, just scripts and styles (it's not in the other issue). main point is that public components shouldn't require jade or something to use the templates, but i wouldn't really mind mustache templates or something where i could just do .replace('{{title}}', 'some title'}) if i really wanted to.

question though is should we just have people store their source files in .files or create a new one called .source or something?

[ianstormtaylor]

.files and .source both don't seem great because they make our semantics weaker, eg. .files prevents us from differentiating between assets to copy and source files to compile. .source also just seems like it would turn into a jankfest since everything will just be thrown in there.

i still don't really think that its a problem keeping them in .scripts and .styles... that's where they make the most semantic sense.

if we really need a separate key the only thing that doesn't seem to cause semantic problems is just doing away with it entirely by using a key for each filetype .coffee .sass but then i'm wondering to myself why are we repeating extension logic now when really these things can just live in .scripts and .styles

if they are to be used for private components regardless, and we really do want to put a warning in publish it shouldnt matter what the private ones do anyways, and can be left up to the component builder extension to decide

[jonathanong]

yeah i was thinking about public components that have to be compiled down to js/css. i guess the source wouldn't end up mattering anyways, so there's no point. we can also defer the .coffee and .sass properties to builders to implement (if they want) and not have component even bother with them at all.

closing! adding #31 to the spec