When using webpack and babel together, one needs to configure both in order to use React CSS Modules. For example:
webpack.config.js will need a rule like this:
{
// Translates CSS into CommonJS modules
loader: 'css-loader',
options: {
modules: {
mode: "local",
localIdentName: CSS_CLASS_NAME_PATTERN,
},
sourceMap: true
}
babel.config.js will need a plugin like this:
[
'react-css-modules',
{
generateScopedName: CSS_CLASS_NAME_PATTERN,
filetypes: {
'.scss': {
syntax: 'postcss-scss',
plugins: ['postcss-nested']
}
},
}
]
Why the need to configure CSS Modules in two places? How the two work together? I.e. what happens in what order?
They don't. css-loader does its own thing: class name transformation in CSS, and replacement of CSS imports in JS code by mappings between original and generated names.
babel-plugin-react-css-modules works independently, and it replaces styleName attributes of react components by className with correct generated names. To do so it calculates class name mappings independently from css-loader, that's why it needs separate configuration matching that of css-loader, and that's why after a few years being abandoned by its creators it has compatibility issues with latest css-loader (css-loader changed internal class name generation logic).
Shameless self-promo: I maintain an up-to-date fork of babel-plugin-react-css-modules which solves compatibility issues with latest css-loader versions.
Related
We are trying to setup a lib in NX with a scope:example tag, such that it can only be imported by other libs with a scope:example tag.
We were hoping to set it up like this:
{
"sourceTag": "scope:example",
"onlyDependOnLibsWithTags": ["scope:example"]
},
{
"sourceTag": "*",
"notDependOnLibsWithTags": ["scope:example"]
}
This doesn't work, because the 2nd rule applies even to the scope:example libs, preventing them from importing other scope:example libs.
We could fix this by adding a new tag to all of our existing libs, so we can replace the * in the second rule with that new tag.
This is not ideal, because if other devs make libs, the rule will not be enforced unless they manually add the new tag to it.
What would be ideal is something like:
{
"sourceTag": "scope:example",
"onlyDependOnLibsWithTags": ["scope:example"]
},
{
"libsNotContainingSourceTag": "scope:example",
"notDependOnLibsWithTags": ["scope:example"]
}
Any help on any means to achieve the desired lint rule? Thanks in advance!
I want to use class property and private fields in my sapper project. Apparently they have to be preprocessed by babel right now.
I tried to add the corresponding babel plugins to rollup.config.js, only to realize a few things.
the babel rollup plugin is only used in legacy mode.
the server part doesn't use babel at all.
I tried to add the babel rollup plugin to the end of server plugins like this,
babel({
extensions: ['.js', '.mjs', '.html', '.svelte'],
runtimeHelpers: true,
exclude: ['node_modules/#babel/**'],
plugins: [
'#babel/plugin-proposal-class-properties',
'#babel/plugin-proposal-private-methods',
],
}),
But it doesn't seem to take effect at all.
I also added it to the client plugins (before the legacy entry), but it complained about I needed to add #babel/plugin-syntax-dynamic-import, so looks like babel has to recognize the whole syntax in order to preprocess, and I don't really want to compile dynamic import for modern browsers.
How do I enable the use of esnext syntax in sapper?
You would need to preprocess the contents of <script>, using the preprocess option in rollup-plugin-svelte:
plugins: [
svelte({
// ...
preprocess: {
script: ({ content }) => {
return transformWithBabel(content);
}
},
// ...
})
]
In an ideal world we'd have a ready-made preprocessor plugin for doing this; as it is, the transformWithBabel function is left as an exercise to the reader for now. Essentially it would involve import * as babel from '#babel/core' and using the Babel API directly, which I guarantee will be lots of fun.
Note that #babel/plugin-syntax-dynamic-import doesn't compile dynamic import, it only allows Babel to parse it. Without it, Babel can't generate a valid AST from the code inside <script>.
I'm working on a jspm/systemjs app and would like to better understand how SystemJS handles multiple versions of the same dependency. Consider the following (simplified) SystemJS config example:
map: {
"react": "npm:react#0.14.8"
"npm:foo": {
"react": "npm:react#0.14.7"
}
}
I assumed when my code imported react it would get v0.14.8, while code in the "foo" dependency would receive v0.14.7. However, my browser console prints warnings about multiple copies of react being found.
Questions:
How does SystemJS supports multiple versions of dependencies,
Why would I be receiving an error like this if the different versions are kept separate?
Since SystemJS uses import-maps, you can use this approach:
Using Multiple Versions of the Same Module
It's easy to require multiple versions of the same package with import maps. All you need to do is use a different import specifier in the mapping as shown below:
<script type="importmap">
{
"imports": {
"lodash#3/": "https://unpkg.com/lodash-es#3.10.1/",
"lodash#4/": "https://unpkg.com/lodash-es#4.17.21/"
}
}
</script>
You can also use the same import specifier to refer to different versions of the same package through the use of scopes. This allows you to change the meaning of an import specifier within a given scope.
<script type="importmap">
{
"imports": {
"lodash/": "https://unpkg.com/lodash-es#4.17.21/"
},
"scopes": {
"/static/js": {
"lodash/": "https://unpkg.com/lodash-es#3.10.1/"
}
}
}
</script>
With this mapping, any modules in the /static/js path will use the https://unpkg.com/lodash-es#3.10.1/ URL when referring to the lodash/ specifier in an import statement, while other modules will use https://unpkg.com/lodash-es#4.17.21/.
Source: https://www.honeybadger.io/blog/import-maps/
TL;DR: Is there a way how to specify the order in which the Babel plugins are supposed to be run? How does Babel determine this order? Is there any spec how this works apart from diving into Babel sources?
I'm developing my own Babel plugin. I noticed, that when I run it, my plugin is run before other es2015 plugins. For example having code such as:
const a = () => 1
and visitor such as:
visitor: {
ArrowFunctionExpression(path) {
console.log('ArrowFunction')
},
FunctionExpression(path) {
console.log('Function')
},
}
my plugin observes ArrowFunction (and not Function). I played with the order in which the plugins are listed in Babel configuration, but that didn't change anything:
plugins: ['path_to_myplugin', 'transform-es2015-arrow-functions'],
plugins: ['transform-es2015-arrow-functions', 'path_to_myplugin'],
OTOH, this looks like the order DOES somehow matter:
https://phabricator.babeljs.io/T6719
---- EDIT ----
I found out that if I write my visitor as follows:
ArrowFunctionExpression: {
enter(path) {
console.log('ArrowFunction')
}
},
FunctionExpression: {
exit(path) {
console.log('Function')
}
},
both functions are called. So it looks like the order of execution is: myplugin_enter -> other_plugin -> myplugin_exit. In other words, myplugin seems to be before other_plugin in some internal pipeline. The main question however stays the same - the order of plugins in the pipeline should be determined & configurable somehow.
The order of plugins is based on the order of things in your .babelrc with plugins running before presets, and each group running later plugins/presets before earlier ones.
The key thing though is that the ordering is per AST Node. Each plugin does not do a full traversal, Babel does a single traversal running all plugins in parallel, with each node processed one at a time running each handler for each plugin.
Basically, what #loganfsmyth wrote is correct; there is (probably) no more magic in plugin ordering itself.
As for the my problem specifically, my confusion was caused by how arrow function transformation works. Even if the babel-plugin-transform-es2015-arrow-functions plugin mangles the code sooner than my plugin, it does not remove the original arrow-function ast node from the ast, so even the later plugin sees it.
Learning: when dealing with Babel, don't underestimate the amount of debug print statements needed to understand what's happening.
I want to implement RequireJS in a very large single page application that uses CoffeeScript and Grunt. We have separate files for different modules (services, Backbone, etc.).
Implementing RequireJS is very straightforward - my main problem is with the size of the application and CoffeeScript's whitespace sensitivity. We need to be able to continuously develop new features while implementing RJS. The reason we cannot do this is because we would have to wrap all files in define calls, and re-tab files. When you try to rebase this code, massive merge conflicts arise due to the tabbing. No one has the time to solve all those problems, as new features and bugfixes may have been introduced pre-RJS.
I've research a few possible solutions:
Stop development and re-tab everything. This sucks because development is stopped until files are tabbed and the code actually works with RJS.
Use CommonJS pattern, and use RJS CommonJS converter pre-RJS optimize. Seems hacky.
Use CoffeeScript backtick functionality to wrap CoffeeScript classes in a standard JavaScript module pattern. Next pass dependencies to the "module" wrapper for the CoffeeScript class then initialize the "module" within the RJS call in the file.
Edit:
Thanks for the tip on the vertical structure & introducing me to passing function arguments that way (comma-less). Our projects are very similarly in structure (except grunt-contrib-coffeee does the linting, unfortunately, at the moment), and I am also building a custom watch task to compile single files (vs. glob patterns).
Consider this very basic example:
view.coffee:
class View
template: Helper.template
constructor: (#options) ->
render: (meters) ->
$('body').html #template #options
The normal process would be to do something like the following with RJS:
define [
'jQuery'
'Helper'
], (
$
Helper
) ->
class View
template: Helper.template 'base_view'
constructor: (#options) ->
render: (meters) ->
$('body').html #template #options
Notice how the entire class has been re-tabbed. Git would hate this if any one of our developers came along and modified the View class, while I was trying to implement require in parallel.
The backtick idea won't work, I can't get around the global problem there:
`var exports = function($, Helper) {
class View
template: Helper.template
constructor: (#options) ->
render: (meters) ->
$('body').html #template #options
return View }(jQuery, Helper)`
define [
'jQuery'
'Helper'
], (
$
Helper
) ->
return exports($, Helper)
I think my best bet is merging all of the applications features together and then pausing for a moment to re-tab every file the necessary two spaces, all in one commit. CoffeeScript doesn't seem to care where the indentation begins (column 0 vs column 2) as long as the rest of the file follows that pattern. We should be able to slide in RJS and implement it progressively in this way, preventing unsolvable merge conflicts.
What we do in our projects:
we use grunt-contrib-coffee and grunt-coffeelint to compile and validate coffee files. With this plugin, you can validate the coffeescript code while developing. You can use a json file which contains validation settings. This makes sure all developers use the same settings.
e.g:
{
"no_tabs" : {
"level" : "error"
},
"no_trailing_whitespace" : {
"level" : "error"
},
"max_line_length" : {
"value": 200,
"level" : "error"
},
...
minimize the chance of merge conflicts in requirejs dependecies by defining each dependency on a separate line.
e.g.
define [
'dep1'
'dep2'
'dep3'
], (
dep1
dep2
dep3
) ->
console.log "Hello"
instead of
define ['dep1', 'dep2','dep3'], (dep1, dep2, dep3) ->
console.log "Hello"
Only commit coffeescript files to source control. Generated javascript files (minified via grunt-contrib-requirejs) we don't commit (only when creating a production version).
we use a custom watch task to watch changed coffeescript files (among other files). Via growl the developer is notified when compilation or validation failed.