Installing react-scripts
from npm can take a few minutes on a reasonably fast internet connection. Increasing the size of dependencies and making the installation time longer is also something that limits us when considering new features like testing (#331).
What if we pre-built react-scripts
into one executable JS file with webpack, rollup or similar module bundler and published the package to npm with just that file? As all code would be in a single file (instead of 13k+ files currently installed to node_modules
) and that file would presumably be a lot smaller than ~77 MB consumed by the separate packages, I would expect it to be very fast to install.
I think this would solve a huge pain point in development using JS build tools: npm install
takes a lot of time. react-scripts
is a single dependency that solves the basic build tool needs and if it installed very fast, the problem would basically be solved for projects using it.
I don't know how well this would work in practice, it's just an idea at the moment, but I wanted to throw it here for discussion. What do you think? Are there any downsides to bundling the scripts like this?
See also #14.
We鈥檙e open to suggestions but we鈥檙e not likely to work on this ourselves anytime soon.
So if you see a way to make it work, feel free to send a PR, and we鈥檒l be happy to discuss!
Still up for some experimentation? :D
After some experimentation with bundling the package with webpack, I think it is going to be harder than than I initially thought.
The biggest problem is dynamic imports, which are common in node packages. Webpack can process some forms like require(expr)
or require("prefix" + expr + "suffix")
, by creating a _context_, which finds all matching files. This pulls in lots of files that aren't actually needed, like tests and docs, and unhandled file types. We could fix this by white/blacklisting the modules that can be bundled and include the rest as "externals", but this would require a lot of manual work, and new packages/versions could easily break it. Also native modules would have to be excluded from the bundle.
This also wouldn't be a common way to bundle a node package, so we might also hit other issues with 3rd party libraries later on. While webpack works with node
as a target, the typical way to use it seems to be to the opposite of what we're trying to do, to set packages in node_modules as externals and not include them in the bundle. This wouldn't help us much, because most of the code in react-scripts
is in the dependencies and bundling them was the whole point of this issue.
I think there aren't going to be any easy wins for the installation speed using this approach, but I'd be happy to be proved wrong. I'm closing this issue for now because I'm not going to work on it in the near future.
Most helpful comment
After some experimentation with bundling the package with webpack, I think it is going to be harder than than I initially thought.
The biggest problem is dynamic imports, which are common in node packages. Webpack can process some forms like
require(expr)
orrequire("prefix" + expr + "suffix")
, by creating a _context_, which finds all matching files. This pulls in lots of files that aren't actually needed, like tests and docs, and unhandled file types. We could fix this by white/blacklisting the modules that can be bundled and include the rest as "externals", but this would require a lot of manual work, and new packages/versions could easily break it. Also native modules would have to be excluded from the bundle.This also wouldn't be a common way to bundle a node package, so we might also hit other issues with 3rd party libraries later on. While webpack works with
node
as a target, the typical way to use it seems to be to the opposite of what we're trying to do, to set packages in node_modules as externals and not include them in the bundle. This wouldn't help us much, because most of the code inreact-scripts
is in the dependencies and bundling them was the whole point of this issue.I think there aren't going to be any easy wins for the installation speed using this approach, but I'd be happy to be proved wrong. I'm closing this issue for now because I'm not going to work on it in the near future.