Modules namedExport with backward compatibility

[SuperOleg39]

Hello!

Had a try to adopt a new feature with named exports to existing project, and have a problem with third-party libraries.

Use case

For example, we have application, with ui-kit library, which export components with css modules, and custom css modules.
Inside ui-kit, components use default exports from css modules (and we can't change this behaviour):

// @some-ui-kit/button.js
import styles from './button.module.css'

const Button = (props) => <button {...props} className={styles.button} /> 

Our components want to use named exports:

// src/page.js
import { foo, bar, baz } from './page.module.css'

const Page = () => <div className={foo}><p className={bar}>text</p></div> 

With current css-loader named exports implementation, we will have a error: "export 'default' (imported as 'styles') was not found in '@some-ui-kit/button.module.css'

Implementation

From this css:

.foo {color: red}
.bar {color: blue}

with special option, generate named and default exports at the same time:

export const foo = 'abc'
export const bar = 'def'
export default {foo: 'abc', bar: 'def'}

This behaviour doesn't break tree shaking.

If this idea don't have any drawbacks, i can try implement it in css-loader and mini-css-extract-plugin

[alexander-akait]

Unfortunately this is not possible, ui-kit should rewrite code on named exports in this case, maybe you can create a babel plugin for this, but we can't rewrite existing code on named exports, it is not safe.

export const foo = 'abc'
export const bar = 'def'
export default {foo: 'abc', bar: 'def'}

Bad idea, named export was created for concatenations modules, using this code will destroy all benefits.

Workaround - you can use test/include/exclude and using different options for different files.

[SuperOleg39]

but we can't rewrite existing code on named exports, it is not safe - i mean additional output, one for default export, one for named, and mixed)

using this code will destroy all benefits - you think tree shaking will not remove default exported object, if only named export will be used?

you can use test/include/exclude - thank you for the good idea)

[alexander-akait]

but we can't rewrite existing code on named exports, it is not safe - i mean additional output, one for default export, one for named, and mixed)

I understand this, why we shouldn't mix this is described below

using this code will destroy all benefits - you think tree shaking will not remove default exported object, if only named export will be used?

And yes and no, depends on how the code is written, but only named always works with tree shaking

[SuperOleg39]

I can't fully understand, why mixed exports is bad)

Have module:

export const foo = 'abc'
export const bar = 'def'
export default {foo: 'abc', bar: 'def'}

Use it at old code:

import styles from 'styles.css'

styles.foo
styles.bar

Use it at new code:

import { foo, bar } from 'styles.css'

foo
bar

Both variants should working well, and allow unused code removing

[alexander-akait]

When you bundle libraries we don't know what should be tree shaking, so using locals in default is bad idea, yes, webpack will try to do tree shaking where is possible, but using named export is best solution here, handling this cases on style-loader increase runtime code (decrease perf too)

[SuperOleg39]

Agreed with that, thanks you!