Can/should this be used to import non-JS assets from node_modules, e.g. CSS / SASS?

[jacobq]

For example, I am using materialize-css, and in addition to being able to import the JS into components I want to @import SASS assets in my styles. Thus far I've been accomplishing this by using something like this in my ember-cli-build.js:

const app = new EmberApp(defaults, {
  // ...
  sassOptions: {
    includePaths: [
      'node_modules/materialize-css/sass'
    ]
  }
  // ...
}

Should I keep doing this or does ember-auto-import do something in this space as well?

[ef4]

There are no conventions, so doing what you're doing is fine.

There are several different possible things people might mean when they think of importing CSS or SASS:

1. Replacing app.import of CSS (or anything that is being transpiled into CSS), so that apps could say import "some-package/some.css" and that would cause it to automatically end up in vendor.css. That's a pretty small change and not hard to implement. I would like to add this.

2. Dynamic import of CSS (meaning await import('some-package/some.css') would resolve once the given CSS is added to your document). This either already works or would be a small addition.

3. Making @import 'some-pacakge' in your SCSS or CSS file automatically resolve to some-package from NPM and cause build-time inclusion. This is also something I would like to do, but it doesn't fit inside ember-auto-import. It's on my world-domination plan, but not until a later stage where the things ember-auto-import are doing have moved directly into ember-cli.

[jacobq]

Thanks for the reply. I am most interested in the 3rd one, as it seems a lot more intuitive to me (at least for a new user) to try node_modules/some-package when doing @import 'some-package' in stylesheets rather than have to find the magic place to wire that up (though once you know it, it is kind-of nice to have it be so explicit).