Allow 'index' to be a possible file to import
anthonyshort opened this issue · 33 comments
It would be great to allow an index.scss file to be imported if a directory is found. Example
@import "./fruits"If ./fruits is found to be a directory, it would look for ./fruits/index.scss or ./fruits/index.sass.
The reason behind this is to make it easier to consume packages containing Sass files. For example.
We can then download packages into a directory, add that directory as a single load path and then in our main file we can easily do:
@import "nib-styles-common";
@import "nib-styles-dialog";Which is a little neater than any alternative.
I attempted to do a pull request for this, but alas, my skills are weak 😢
I love this idea.
This seems reasonable to me.
Isn't this basically Sass globbing?
Not really. It more like an alias. It could theoretically live anywhere. If Sass packages all do this then there is a guaranteed, single entry point for every library.
I think we should make this part of 4.0 when we add our module system. it
may be better to use a different file name than "index" that is in keeping
with whatever we come up with for our modules. E.g. _module.s[ac]ss.
I think I see your point. So the difference is:
- Sass Globbing: imports all files in a directory or directory tree
- Index Importing imports only the index (or whatever naming convention is used) in a directory, reducing functionality but enforcing a uniform rule
If this rule would be for all stylesheets, including site/application stylesheets, _style might be better — index is an odd conflation with html. Chris's suggestion _module works too.
index is nice because it's consistent with conventions used by other languages, but we would want it to be a partial. _index is less similar, so _module might be a better way to go for that reason.
I only suggested index because that is what I'm used to with node and Component. The name doesn't particular matter too much. It would be nice to get this before 4.0 as it seems like it could be trivial to implement and would make using Sass with tools like Bower and Component easier.
@robwierzbowski Globbing won't really work with a module system though. Modules should have a single entry point where they 'export' what consumers need.
@anthonyshort You're totally right. Took me a min to get my head around it.
After working with node fort a few weeks, I take back my objections to _index.scss. Of all the options it's now the one I prefer the most 😄.
+1
Totally wish I had this feature right now...
Some people would prefer the name _module.scss. Others would prefer _index.scss, _style.scss, _component.scss, _loader.scss or something else.
It would be great if the name of the index file could be configured, so we could all use our own personal preference.
index or _index look reasonable. +1
+1 in general. Coming to Sass I kinda expected this feature to already be implemented and thought I had discovered a bug.
@jslegers -1
If you allow customizing the name of the index file, you'll end up with incompatible vendor packages. If vendor A settles for _module.s[ac]ss, but vendor B goes with _entry-point.s[ac]ss and the user (you) decides to use _index.s[ac]ss, they won't be able to use any of the vendor's packages/modules.
Besides that, there is no such thing as a config file. You'd either have to mingle this config into your Sass files (very ugly!) or pass it as an option to the compiler (not much less ugly).
Sass should decide which name to use to prevent this mess. I recommend using _module-index.s[ac]ss or _import-index.s[ac]ss, depending on wether or not this gets implemented in dependence of the module feature. The name is expressive and the risk of already having partials named like that is fairly low.
@chriseppstein I recommend getting this in before the module feature, as this is a low-level feature in the language. It's virtually nothing different than a macro. The @import "some/directory" statement should be availabe, without having to use higher-level concepts such as modules.
I'm highly anticipating this feature and would love to see it before the next major version update, especially in libsass, as that's what I'm using! :)
As soon as the core contributors can settle on a name or chain of names (look for xyz, if not found for abc, if not found for ... - however I discourage this), this rather "trivial" patch could be implemented in libsass and would be available to thousands of Node.js users in an instant.
Agreed, @phvcky. A good tool needs to have constraints. Customizing the name of the index file is needless complexity. The benefits are miniscule in comparison to the problems such a feature invites.
I would also favor index.scss or _index.scss as index by itself is widely used in other web technologies as well. Seems consistent to me.
👍
Any updates on this? I would really love to see this feature implemented.
I agree that this is a solid idea and would like to see it implemented as a core feature of Sass. I also proposed something similar to libsass sass/libsass#546
👍
👍
I'd give my vote for index.scss and _index.scss.
Alternatively, Sass could (also) look for some config file, like packages.json in case of node. it will allow modules to be more flexible, point to index files and, in fact, even to depend on other modules.
Yeah, I'm going to strongly recommend that we re-work this issue into something a little more specific. Also, I am very against "_module" because of confusion with our upcoming module system. This seems to confuse the concepts of modules and a directory import... it's not clear about the relationship here.
Is @import "folder"; the same thing as the upcoming @use "folder" as "f";? To me, this issue doesn't resolve any of the issues with real modules, and this seems more like something we'd implement as part of the current sequential-import system we use, instead of a more complex module/dependency tree.
If we were going to do this as a simple bulk-import / non-real-module system, I'd highly suggest some form of index as that's a lot clearer that it's job is to list files, instead of actually defining a full module interface.
I don't think there's a problem with having a module entrypoint that exposes the full API of that module, if that's what it wants to do. For example, if someone wants to release a small package with a single mixin or something, there's nothing wrong with having the entirety of the package be in _index.scss.
I'm very sad this is still not in?
For what its worth, we recently discussed our own naming conventions on my team... we decided not to use _index.scss but instead have the name of the file match the parent directory. This way we don't have a bunch of files named _index.scss, so its easier for devs to follow in their IDEs and when searching by filename.
It would be nice, when implementing this in 4.0, if it behaves similarly to common/node standards... where it identifies the directory as a package, looks for the directory name as _{directoryName}.scss, then, if it finds none, it looks for index.scss. https://nodejs.org/api/modules.html#modules_folders_as_modules
Any news about topic?
Indeed still waiting for this feature. The setup is already ready, only the urls in the main app.scss have to be altered. When is this coming?
I think the labels pretty clearly indicate the status of this proposal: we like the idea, but we don't have the resources to devote to it at present.