Add support for file extension placeholder and function in output.entryFileNames option

[awmottaz]

See also

• This feature proposal is follow-up for output.entryFileNames is ignored with preserveModules: true #2847 (comment)
• output.entryFileNames - accept a function? #2585

Feature Use Case

If I enable the preserveModules option, I get undesired filenames in the build output. For example, I might name a CSS module the same as a component with only the file extension distinguishing the two files:

src/
  FooComponent.jsx
  FooComponent.scss

Today, the output from using preserveModules: true will give me

dist/
  FooComponent.js
  FooComponent2.js

Feature Proposal

Add a placeholder for the file extension that can be used in the output.entryFileNames template option, and add support for specifying a function, so that if I have this configuration:

export default {
  input: 'src/FooComponent.jsx',
  output: {
    dir: 'dist',
    format: 'esm',
    entryFileNames: id => /\.(jsx?|tsx?)$/.test(id) ? '[name].js' : '[name].[ext].js'
  },
  preserveModules: true,
  // other options
}

I get this build output:

dist/
  FooComponent.js
  FooComponent.scss.js

[Andarist]

Im not using rollup as general purpose bundler, i just build npm libraries with it. So I’ wondering - what’s the output when u dont use preserveModules and u handle scss etc through rollup?

[awmottaz]

@Andarist

what’s the output when u dont use preserveModules and u handle scss etc through rollup?

If the preserveModules option is not provided, Rollup will be bundling the code (it's default behavior). I would need to modify the output options to account for this:

export default {
  input: 'src/FooComponent.tsx',
  output: {
    file: 'dist/FooComponent.js',
    format: 'esm'
  },
  // other options
}

The output from the build would just be

dist/
  FooComponent.js

with the SCSS module included within the dist/FooComponent.js file.

[Andarist]

Interesting - I would have thought that SCSS would produce a separate CSS file 🤔

[awmottaz]

It can, depends on how CSS modules are set up.

Regardless, the requested feature is still useful for all kinds of workflows beyond the specific example I gave.

[Andarist]

I'm just wondering about the exact workflow here - so the solution can be implemented with all things in mind. In this case, it's somewhat weird for me that SCSS can compile down to regular JS instead of emitting a CSS which in turn would be turned into a "virtual" JS file (if needed).

It is what it is though and even might be a good thing, I certainly haven't spent that much time thinking about this.

Seems to me that in this case, we should be able to do a "good thing" by default - supporting [ext] is ofc still on the table. It shouldn't be needed every time though, only when one really wants to change the default pattern.

By doing a good thing here I mean special casing known js~ extensions (js,jsx,ts,tsx) and using current pattern for them, but using '[name]-[ext].js' (or '[name].[ext].js') for everything else. WDYT? cc @lukastaegert

[awmottaz]

I'm just wondering about the exact workflow here - so the solution can be implemented with all things in mind.

I'm working on a component library, the setup is like this:

src/
  index.ts # re-exports the components
  components/
    Foo/
      Foo.tsx
      Foo.scss
    Bar/
      Bar.tsx
      Bar.scss

The *.scss files are imported by the *.tsx files as CSS modules. In the build, I'm using a PostCSS plugin to extract the styles into a common index.css file, and each of the *.scss files is converted to a JS module which exports an object whose keys are classnames defined in the *.scss to the generated scoped classnames. The ideal output would look like this:

dist/
  index.js # transformed entry point, re-exports the components
  index.css # generated styles with scoped classnames
  components/
    Foo/
      Foo.js
      Foo.scss.js
    Bar/
      Bar.js
      Bar.scss.js

As an example, if the Foo.scss source code defines styles for the classes .outer and .inner, the styles would be emitted as part of the dist/index.css file and the Foo.scss.js file in the output might look like this:

var css = {"outer": "Foo__outer_8dF76", "inner": "Foo_inner_kjLU7"};

export default css;

[Andarist]

Ok, I get it now - so the CSS asset gets emitted, just "elsewhere" (a single index.css at root or smth). Thanks for clarifying this.

[awmottaz]

You're welcome!

Another use-case is when using SVGR which transforms *.svg images into React components directly (no other emitted assets). It would be nice to name those *.svg.js in the output.

[Andarist]

I've prepared a PR fixing the original issue here - #3116

[bhabgs]

I'm just wondering about the exact workflow here - so the solution can be implemented with all things in mind.

I'm working on a component library, the setup is like this:

src/
  index.ts # re-exports the components
  components/
    Foo/
      Foo.tsx
      Foo.scss
    Bar/
      Bar.tsx
      Bar.scss

The *.scss files are imported by the *.tsx files as CSS modules. In the build, I'm using a PostCSS plugin to extract the styles into a common index.css file, and each of the *.scss files is converted to a JS module which exports an object whose keys are classnames defined in the *.scss to the generated scoped classnames. The ideal output would look like this:

dist/
  index.js # transformed entry point, re-exports the components
  index.css # generated styles with scoped classnames
  components/
    Foo/
      Foo.js
      Foo.scss.js
    Bar/
      Bar.js
      Bar.scss.js

As an example, if the Foo.scss source code defines styles for the classes .outer and .inner, the styles would be emitted as part of the dist/index.css file and the Foo.scss.js file in the output might look like this:

var css = {"outer": "Foo__outer_8dF76", "inner": "Foo_inner_kjLU7"};

export default css;

I want to know, how to setting .tsx compile

[frank-dspeed]

Closed by: #3658