dbashford / mimosa

A lightning-fast, modular, next generation browser development tool.
http://mimosa.io/
519 stars 34 forks source link

Allow files of same name but different extension to be written out #266

Closed Anachron closed 10 years ago

Anachron commented 11 years ago

Hi there,

I'm wondering about the support for using multiple metalanguages (such as LESS & Stylus) in the same project?

I haven't really tried yet but I am kinda confused because of the Skeleton and how it would handle two files with same name but different extension? (for example one .coffee and one .ice file?)

dbashford commented 11 years ago

Same name different extension would work as long as they aren't in the same folder. If style.less and style.styl both lived in stylesheets, they would both output style.css and overwrite each other.

Does that answer your question? As long as you don't have that kind of collision, you should be fine.

Anachron commented 11 years ago

Yeah, I was talking about having two files with the same name just different extension in the exact same folder. Isn't it possible to create a hash and store it based on the hash?

dbashford commented 11 years ago

Mimosa could do something to support that. It could, for instance, output style.styl.css and style.less.css. Could generate some reusable hash base on the file's full name. I would probably not want to put any kind of auto-detection of this very rare use case in place though. I would not want to have to check every time I write a file to see if another file already exists...and if that came from a different extension, etc. Given not having auto-detection, I'd need to provide some way to map input files to output file names in the config so that you could do this:

  outputFileNames:
    "path/to/style.styl":"style.styl.css"
    "path/to/style.less":"style.styl.less"
Anachron commented 11 years ago

I was thinking about something like that, however, it's kinda rare and it's just an idea of me in my mind. After all, I wouldn't do that by myself, but I want to create skeletons that allow users to do that. At least, it's a possible thing to implement.

As for now, there is no need to implement it into the core. Maybe in the future?

dbashford commented 11 years ago

Ya, given my short-term focus on 1.0, skeleton creation and site updates, I wouldn't get to this for at least a month or so.

Anachron commented 11 years ago

Okay, so tag it to a future release. Honestly, I can't wait to see the new skeleton support.

dbashford commented 11 years ago

I'm a little confused, which new skeleton support? Stuff you are building, stuff we've talked about or the skeleton stuff that is already built into Mimosa?

Anachron commented 11 years ago

I mean you told me about 1.0 which is all about skeleton creation and site updates, which indicates that there will sooner or later be some changes to skelmimosa too, right?

As for now, Mimosa needs a lot more Skeletons. Did you see Meteor.com, by the way?

dbashford commented 11 years ago

All the skeleton work is done. The skelmimosa is now a part of Mimosa core so the skel:new, skel:list and skel:search commands are all immediately available.

I've beefed up the registry so that it contains more meta-data with the hopes of someday soon tossing an app in Heroku to allow for some skeleton registry exploration.

Familiar with Meteor, not used it though.

Mimosa does need more skeletons. I know someone is working on an Angular one. I hope to get to a simple Backbone one, maybe as part of the effort to build the skeleton exploration app. I would love to have 100 skeletons. =)

Anachron commented 11 years ago

Okay, see. So the 1.0 RC1 will be coming out soon then? I was the one working on the AngularJS & AngularUI one ;) I'm planning to do more Skeletons, but as for now, I am kinda "disappointed" / unhappy with the Mimosa folder structure that keeps my projects a little limited.

Anachron commented 10 years ago

I've just noticed that allowing this will break some design patterns. Maybe it's better to not support it. What do you think?

dbashford commented 10 years ago

I am happy with that. I think its a pretty unique use case. It's one thing to support two languages with the same name in different folders, but the same name in the same folder is a bit difficult. Whenever I got around to checking this out, I may have just decided to not support it anyway due to unnecessary complexity to support an odd use case.

Anachron commented 10 years ago

Okay, I will close this then.