I am using reactstrap in my React app which was originally created by create-react-app.
The problem I'm having is with reactstrap, I'm getting the following console warnings:
./~/reactstrap-tether/dist/js/tether.js
Critical dependencies:
2:479-486 This seems to be a pre-built javascript file. Though this is possible, it's not recommended. Try to require the original source to get better results.
# ./~/reactstrap-tether/dist/js/tether.js 2:479-486
In the project's GitHub issues, I see possible solutions listed like so: "To suppress the warning (for now), add this to your webpack config file...". The problem is, with Facebook's create-react-app I do not have a Webpack configuration file to configure. How can I go about fixing this warning
Looks like this has raised concern for people with create-react-app and a feature request has been put in and is currently being worked on. It should be fixed in the near future so there you shouldn't really worry about it. But to answer the other part of the question, it's possible to get the Webpack, Babel and other configuration files from create-react-app by running npm run eject but since this is an irreversible action and will separate you from future updates, I would highly suggest just waiting for the fix to happen.
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.
I'm working on a project built by someone else. I know it was bootstrapped by create-react-app because it says so in README.md.
However, I'm not sure if it has been ejected or not. There are many posts out there teaching you how to actually eject it, but I failed to find a way to check it in the first place. Any help is appreciated!
Some immediate giveaways that a create-react-app project has been ejected:
The dependencies field in package.json no longer contains react-scripts. Instead, it is populated with many additional packages like Babel, Eslint, Jess, Webpack and various Webpack loaders.
The absence of eject script.
The start, build and test no longer follows this format react-scripts start, react-scripts build etc.
A new directory named config appears.
Just sharing because you may or may not see all of these signs in your project as they were probably ejected a long time ago. I hope no one will spend two hours wondering why a certain package didn't work only to discover that the project has been ejected and the package only works with unejected ones.
Many thanks to #YuryTarabanko!
So I tried creating another project using CRA and ejecting it. Right after the ejection, a new directory called config popped up and there were some modifications in other directories, too.
Then I took a look at the project I'm actually interested in. The config directory is right there, with a structure similar to that config dir in the new project that popped up after the ejection. So I'm sure this project has been ejected, too!
Edit:
As Yuri pointed out in the comment:
The most noticeable difference IMHO would be the absence of eject command in package.json#scripts section though ;)
I somewhat agree with the script in package.json, but it could have easily been removed. If the project is in a repo, you should be able to look at the history of a few files to be certain.
I merged my branch with master, git merge master, and had a few conflicts. When I did this, my app was running and threw parser errors about the <<<<<<<... lines as expected.
I resolved the merges and now I'm getting the same error, but there is nothing in my code!
I can search the project for <<<< and find nothing. I've restarted my app npm run start, even switched branches, and it's stuck there. Made a new folder and recloned the project and that cleared it out. Any idea why/how this happened? How do I make sure this doesn't happen again.
It seems that a cache problem exists between webpack cache and resolving git conflicts.
the solution is:
stop your app
remove node_modules/.cache
start your app
It's possible that when you were trying to resolve the merge conflicts, pieces of your code were not marked as resolved.
A personal tip:
Using a GUI interface when resolving merge conflicts will help tremendously.
Applications like Github Desktop or using Github's own merge conflcit resolve will help better see your changes.
tldr; How do I configure my CRA project so that the yarn start yields a build compatible with an older browser?
Not sure what I'm doing wrong, but I'm essentially using TypeScript with CRA, and would like to run the development version on an older Chrome. To be precise, it's Chrome 53 running on a Smart TV. As I'm developing an app to run on a TV, and would like to test on the one I have available, running the a build compatible with that TV is crucial.
When I run the current development version on the TV, the browser complains about a syntax error. Probably because of the advanced JS features contained in the build (arrow functions, const, ...).
So the first thing I did was to update tsconfig.json to target es3 instead of what it currently sits at: es5. I was not expecting this to make a difference as ES5 should clearly run well on Chrome 53.
Then, I tried customising the browserlist in package.json to include that version of Chrome, or even copying the production setting to the development ones, but to no avail. When I inspect the JavaScript generated on my desktop, it still contains ES6 features.
Clearly, I'm very unfamiliar as to how TypeScript and CRA (hear Babel) work together. I tried to inspect CRA's source code, and to eject the application to explain my attempts do not work, but I'm lost.
(Noting that the project was created from the CRA's TypeScript template a few days ago, so it's really up to date.)
Well, it turns out that the problem is easier than it appeared. The NPM cache needs to be cleared after modifying package.json. I'll admit that I did not notice the mention of this in the documentation.
When editing the browserslist config, you may notice that your changes don't get picked up right away. This is due to an issue in babel-loader not detecting the change in your package.json. A quick solution is to delete the node_modules/.cache folder and try again.
Supported browsers
I have a React-webpack web app (client side only - no API server) and was tidying up the package.json file and it occurred to me that all of the dependencies are dev dependencies as you do not run the React web app in production - you build it and distribute the built files.
Is this right?
React and possibly ReactDOM would be dependencies. Any additional libraries you're using that appear on the page would also be dependencies (example: react-autosuggest). Everything else would generally be a devDependency.
There's no great consensus on this yet (see this webpack issue, for instance). Some folks want to do everything as a dependency, others as a devDependency, I'm sure you could make a case for bundled dependencies, etc. The solution I outlined above is a best practice that seems to work well. For example, if you're using a version range on a package, you likely wouldn't care about minor/patch version change to webpack, eslint, karma, mocha, etc. You'd most certainly care about even a patch level change to something like react, so it gets separated out into a much shorter dependency list. (Looking at one project, there seems to be a 4-5x difference between dependency and devDependency. It's much easier to spot the meaningful changes if you corral them into the dependency tree.)
Related: yarn takes the approach I outlined above.