feat: Handle scss, sass or less as input correctly

[daniel-rose]

Currently, inputs of type scss, sass or less are rendered with the script tag. This pull request ensures that the link tag provided for this purpose is used.

Here is an example vite configuration that can be used to simulate the problem:

...

export default defineConfig(({ mode }: ConfigEnv): UserConfig => {
  ...

  return {
    server: {
      origin: 'http://foo.bar',
      ...
    },
    build: {
      manifest: true,
      rollupOptions: {
        input: ['./src/foo.tsx', './src/scss/bar.scss'],
        ...
      },
    },
    ...
  }
})

[mindplay-dk]

hi Daniel,

sorry, but I don't understand the use-case or the changes you're proposing.

when or why would you have an .scss (etc) file as an entry-point?

are you building a library? and in that case, why would you want to emit tags?

are you just trying to make the CSS load? in that case import "/scss/bar.scss" from foo.tsx and it should preload.

either way, I'm not comfortable merging a change like this without test coverage.

[kirk-loretz-fsn]

This is exactly what I need!

Here's my use case: I have a legacy PHP app with per-page .scss files that I'm migrating over to Vite. I don't always have corresponding .js files that I can import each .scss file inside, so I need the Sass/CSS files as entry points in Vite.

I could make, .e.g., foo.js that has a single import "foo.scss"; in it, but the built foo-hash123.js entry would be empty. And there's no point in loading <script type="module" src="foo-hash123.js"></script> when that file has no JavaScript.

[mindplay-dk]

Sorry, but it's been 6 months, I don't even know what this issue was about anymore.

I am not currently working with PHP, so this is probably not something I will look into again anytime soon.

I will leave this issue open, but if you need something changed urgently, you should probably just fork. 😌

[mimmi20]

any news?

[mindplay-dk]

any news?

not from me - as explained, I don't use PHP at the moment.

it seems there are now 3 of you who are interested in this feature - if you'd like to explain why it's needed etc. (see above) and assuming the change gets updated with test coverage and docs (if needed) I'd be happy to merge this.

[mindplay-dk]

(it sounds like this change addresses a problem? so a PR should include a failing regression test in a prior commit.)

[mindplay-dk]

Closed in favor of #6