Why CommonJS?
morewry opened this issue · comments
Dunno if I maybe missed this conversation, but how did you decide which formats to build? There is existing Sass code, so I assume that's why SCSS is one format. The new efforts are using CSS Modules, so that's why on that format.
But why is CommonJS the only JavaScript format? My current understanding of the UI components is that they will be using ES Modules, not CommonJS modules? I'd expect in that case for ES Module sto be one of the formats in which the tokens are available.
We added this format because C4 was already doing Styled Components with the new Restref Site and we wanted to allow them to integrate DT. This was a bit before we agreed about using CSS modules. I think the plan agreed with the team was to remove this format once they would migrate to CSS modules.
Perhaps, we could add in the docs that people shouldn't be encouraged to do use that format as it's going to be deprecated? ( 👍 👎 )
EDIT: Just deleted my original comment...slow day. We should be able to just import tokens directly from the CSS files in JS (provided you have the proper webpack plugins set up). So, neither an ES or commonjs module should be needed for anyone.
Anything I'm missing?
Though, I think @morewry 's original questions was simply why we are distributing a commonjs module vs an ES module, which I assume the reason is simply for backwards compatibility (and babel already transparently handles importing from commonjs modules anyway).
Woops I hit the wrong button.
@cbeley Yeah, that was mainly what I was wondering. Was it for backwards compatibility or for use in new components? And, by extension, were there any thoughts on whether we'd be likely to add ES Modules for consistency--or, given webpack use, lean toward using theo-loader on the raw JSON/YAML format on new things.
I see no problem adding ES modules support to the build system here, but - as alluded to by @matteofigus - there shouldn't be much need to do that if you have CSS module imports working. But for example maybe there's need for legacy code to directly import and use the token values (dialog box, iframe, e.g.) and then you could import via ES or CommonJS.
Okay, clarifying questions, @lastquestion. In your comment are you assuming that the tokens will mostly only be used within the CSS Modules? If so, is that because that's the only places their values will likely be needed? Or is it because you, for example, get a map of the values as part of the imported CSS Module when you pull it into the JS portion of a component?
@morewry the latter. According to https://github.com/css-modules/postcss-icss-values#importing-value-in-js, which is the library that we are using in start, it should just work.