Hi I am developing an application using React and Webpack and Gulp.
Webpack gives us the ability to use both CommonJS style and ES6 style.
But I want it to be consistent. I want to use only ES6 module style and want to throw an error if someone uses require syntax.
How to restrict webpack to use only one Module style?
Webpack scans your files. During this process, it uses Babel to transpile import statements into require statements, which Webpack understands. Bundled JS is output of this process. Often, it's unreadable for human.
What you should do is to use ESLint. Use some of ESLint rules/plugins.
To enforce imports, pick this one, for example.
https://www.npmjs.com/package/eslint-plugin-import
Use it in editor or as part of build step...
Note: Webpack2 supports native import statements
Related
I'm writing a library that exposes some React Components as part of its API.
I'm going to make a few assumptions here :
1 - It is going to be used inside react projects.
2 - Those projects will bundle their dependencies at some point.
3 - Those react projects can use JSX as a way of describing the UI.
4 - Their bundler of choice, Webpack if it's a create-react-app, will use babel in order to parse and transpile that JSX into vanilla JS.
Following that logic, I should be able export some JSX from an external package, because the package's code will be bundled, transpiled alongside the app.
However, when I do so in a create-react-app project, I get the following error :
SyntaxError: /Users/someone/Desktop/someproject/dist/esm/index.js: Support for the experimental syntax 'jsx' isn't currently enabled (35:13):
Add #babel/preset-react (https://git.io/JfeDR) to the 'presets' section of your Babel config to enable transformation.
If you want to leave it as-is, add #babel/plugin-syntax-jsx (https://git.io/vb4yA) to the 'plugins' section to enable parsing.
Yes, I could transpile the JSX, maybe I will. I just don't see any reason to, if it's going to be bundled anyway. I prefer leaving transpiling tweaking and optimisation to the user.
My concern is that if I transpile it myself, I have 2 choices.
import React in scope, and using babel to turn <MyComponent/> into React.createElement(), but this will rule out the possibility to use the new JSX transform
use the new JSX transform myself, and figure out whether or not my code will be compatible with react versions prior to 17. And increase my own bundle size because there is a lot of code added by babel to make that work.
At this point, I think I'm quite excited about this issue because frankly I have no idea why I can't just export plain JSX from my package. I know I'm probably missing something obvious, like a semi-colon or whatever, but I really want to understand.
If you want some code / rollup - babel configs feel free to ask.
Tanks !
Your logic seems to make sense at first glance. But let's examine why this is a bad idea.
JSX is a special syntax that must be transpiled down to the lowest common demoninator to be understood in the browser, or by Nodejs. This is what bundlers do, and as you mentioned, anyone working with react in a node environment is almost certainly using a bundler to do this.
However, there are any number of wierd syntaxes that people may use in their code. When a bundler imports code from a node_module, if the code in those modules is not already transpiled, the bundler would need to transpile them as well. Considering un-transpiled modules may be in any number of strange syntaxes, each module would need its own transpilation instructions (think babel configuration). Having unique transpilation configurations for every node_module would be very unwieldy, not to mention having to transpile each node_module, potentially in a different way, would be bad for performance.
The generally accepted best practice for solve this problem is to simply build your package using a bunder which boils the code down to the lowest common denominator. This enables your package-user's bundler to just bring in the code in a node_module "as is".
While its probably possible to come up with some crazy babe/webpack/rollup instructions to custom-interperet your module as JSX, do you really want your library users to have to do that? Especially in the case of people using create-react-app, customizing the babel config of CRA is not natively supported, which means they will need to take extra-steps to get your library to work. Additionally, webpack defaults to excluding node_modules from js transpilations for obvious performance reasons, and CRA follows this convention. When publishing libraries, you want them to be universally useable as easy as possible to consume.
Transpiling, tweaking, and optimizing code is best left to the person who wrote it, which in the case of a react component library you're trying to publish, is you.
Is it necessary to configure React Project without babel which is a transpiler for JavaScript (turning ES6 into code that runs in your browser) ? or with babel as es6 is necessary to use in React projects?
Well, Babel is not really needed but writing React apps without JSX is not something a sane person would do.
Writing React without Babel is not viable honestly.
I was looking at the wiki page of vue.js and saw this:
When compared to React development, Vue can be integrated to an
existing web application much more easily. Normally, a web application
can start using Vue immediately by simply including the Vue.js
JavaScript library. Usage with Webpack or Browserify, are not strictly
necessarily. This is in stark contrast to React development where
Usage with Webpack and Babel is unavoidable, therefore making
converting existing web application much more difficult.
Can someone explain why React needs webpack and babel? I thought you can just drop in the link to the CDN of React and it will work?
No, Babel and Webpack is not necessary for React stack. You can still find other alternatives to build your favourite stack such as Browserify and Gulp.
However, if you want to make things easier, I do recommend you learn and use Babel and Webpack together with React because:
You can use modules.
You can use JSX with ES6.
It support a lot of browsers
You can use more advanced features (async/await) etc
With webpack
You can use different loaders for sass, less, postcss etc
You can use different plugins to optimise your build such as Uglify, HotModuleReplacement, Chunks etc
There are many more advantages to use webpack which you can find here
Can someone explain why React needs webpack and babel? I thought you can just drop in the link to the CDN of React and it will work?
React doesn't "need" babel or webpack but the library is built on the concept of using ES6 javascript syntax and JSX (essentially HTML in JS).
React however can be used without ES6 and JSX which would remove the initial need for Babel but you would lose the potential benefits of ES6 and JSX.
Webpack is separate from React but commonly used in React projects for reasons MattYao mentioned.
In comparison to Vue, JSX to me brings the benefits of containing html, css and JS in one file/component which is what Single File Components in Vue also try to achieve. These would also require a build step using something like webpack as well.
React uses JSX syntax to make writing react more familiar to we the programmers. However, the browsers do not understand JSX. Therefore babel is required to convert your JSX into javascript which is then manipulated by ReactDom and then input into your DOM for the browsers to understand.
I'm trying to use webpack to refactor a backbone application that uses no modularization at all.
All the models and the views are added through script tags to index.html and are globally available.
I have read a couple of tutorials about refactoring with webpack but they only seem to take into consideration the use of webpack on applications that already use modules.
Do you know if there's a way of adding webpack to an app like mine without having to refactor every single js file?
Thanks
You will have to modify each of your js files some, but Webpack will automatically treat each file as a module for you (similar to wrapping every file in an IIFE http://benalman.com/news/2010/11/immediately-invoked-function-expression/).
What you have to do is define which modules have dependencies on other modules. Module's that have dependencies need to define those. Webpack supports many module syntax's, and comes with Commonjs and AMD out of the box. Commonjs is the recommended syntax for webpack. The best place to start is probably this guide:
https://github.com/petehunt/webpack-howto
I'm trying to use webpack with my angular-meteor application. Unfortunately the meteor build fails with the following error:
While determining active plugins:
error: conflict: two packages included in the app (pbastowski:angular-babel and webpack:webpack) are both trying to handle *.js
The angular-meteor package has a dependency on pbastowski:angular-babel for ES2015 support, while webpack uses the babel-loader. Any idea how I can avoid this conflict?
This is a Meteor message that will appear when two Meteor packages try to add a Meteor compiler plugin for the same file extension, in this case ".js".
Option 1
Remove webpack:webpack from your project. Do you really need webpack in your Meteor project? Meteor bundles everything for you, so, there is no need to use webpack, as such. If you want to use ES6 modules then consider using pbastowski:systemjs.
meteor remove webpack:webpack
I don't know your reasons for using webpack, but I thought I'd mention this option.
Option 2
You can configure pbastowski:angular-babel to not compile ".js" files by adding the line below to babel.json in your Meteor project's root folder. However, if you do this, Babel will only compile ".es6.js" files and not ".js" files.
babel.json
{
"extensions": ["es6.js"]
}
Some people here are trying to say that Webpack is useless but they really don't know much about it.
It can helps you bundle a lot better your assets.
You can bundle better your CSS and even have local CSS (css that is not applied globally but only in a section of your page)
You can do code splitting and not serve your entire app on the first page load
You can have hot-reloading with no page refresh (at least with React ;))
You can use angular and Webpack together without any problem. Here is what you need to do:
meteor remove angular
meteor add angular-meteor-data
meteor add angular-templates
The only missing piece then is ng-annotate and luckily, there is a few ways. You can use the ng-annotate-loader or ng-annotate-webpack-plugin in your Webpack config file.