9 ms·

Create-React-App 3.3

114 points by revicon 7y ago

tomashubelbauer 7y ago
Isn't it odd that the removal of --typescript in favor of --template isn't considered a breaking change?
- acemarke 7y ago
  It's not removed, it's just being deprecated. I would assume it would only be removed in 4.0: > For TypeScript users, we're deprecating --typescript in favour of --template typescript.
- Vinnl 7y ago
  You only run that when starting a new project, right? So no existing projects would break when it's actually removed, because they'd never run it again.
JMTQp8lwXL 7y ago
Question for people who use these CLIs to start projects: Since there's so much prebaked functionality in the generated code, do you get distracted by it, when working on it? The CLI probably enables a few dozen features, of which you might use a handful of. So there's all these files and configuration code in your project that is never touched/used. I imagine it's a lot of white noise. Whenever I start new projects, I cleanroom start with an empty git repo. Every line, in every file, has a purpose. (With time, there is some slippage. A feature could get removed, and some code doesn't get eliminated that should, for example). But all in all, the vast majority of the code there serves a purpose. Little to no mental energy is spent worrying about side effects or filtering through code that's not only not relevant to my current work, but has no present value in the project at all. I take a functional style, with the above, to allow myself to really be able to focus on my work. I sometimes feel alone in this approach, but it works for me and I see it's benefits. I place a big premium on clarity.
- SenHeng 7y ago
  I typically start such a new project by cloning from a boiler plate repo that I created myself. I find those easier to use than CRA.
  - rajatsharma91 7y ago
    That's a good strategy, I occasionally use that too, but a better strategy is to keep isolating often repeated functionality in your project and turn them into library packages, so you can simply add them as a dependency from now on. This way, you boilerplate becomes smaller over time or you can even start from scratch easily.
    - jholman 7y ago
      The repeated functionality that belongs in a boilerplate is literally all that CRA does. That's what makes a boilerplate a boilerplate.
  - JMTQp8lwXL 7y ago
    I have my own babel+webpack+etc repo I clone for mini-things I want to dig into (e.g., how does "tool x" work?) and I can freely explore learning that tool, without clouding my production important code base. I then transport those learnings back, and the implementation is more refined, since it's clearly written by somehow who knows how to effectively use Tool X, without haphazardly throwing it around.
  - Keats 7y ago
    I do the same. I find it much easier to understand and I've always needed to modify the config anyway. I wrote about my own boilerplate in https://www.vincentprouillet.com/blog/react-typescript-webpack-1/ https://www.vincentprouillet.com/blog/react-typescript-webpa... and the Webpack config is like 75 lines. It could work with Vue or anything else just as well. My guess is people still think Webpack is hard to configure despite that being quite simple now.
  - 52-6F-62 7y ago
    I do the exact same. I find this is especially important where license and dependency management is a concern.
cageface 7y ago
I think a lot of people have been waiting for this in order to start using the new optional chaining and nullish coalescing operators. Thanks to the Typescript and CRA teams for making this happen. This will be a nice quality of life enhancement.
davedx 7y ago
Hmm. I’m a frequent user of cra but this release reads quite confusing. What are templates and why do I need them? Why are there 3 different package tools used (npx, npm, yarn)? What is all that babel config for? I have to be honest, the main reason I use cra is so that stuff is abstracted away, and this release looks like a lot of it is starting to “spill back out”. Don’t want this to be purely negative though. I am a huge fan of cra overall and it has helped me immensely with setting up new projects and prototyping. Just hope the core simplicity will stay.
- acemarke 7y ago
  CRA's default template gives you several files in `/src`. In the default template, most of those files are intended as examples: - `index.js` is required as the entry point for the app - `App.js` is the main app component - `App.test.js` shows you can write a test for a component - `App.css` shows you can import CSS files directly into the JS to have it included in the output You can begin editing those files, or just delete all but `index.js` and start writing your own. Many folks who have used CRA will just immediately delete those. Beyond that, some folks have forked the `react-scripts` package just to set up a different project source template. Adding an option to specify a template means that other folks can now publish their own CRA-compatible project source templates and have them work with CRA right away. For example, I'm a Redux maintainer, and we could create a CRA template that already has a dependency on Redux (or our new Redux Toolkit package), all set up and ready to go without the user having to manually install them. The different package tools mentioned in the release notes serve different purposes. `npm` and `yarn` are competing JS package managers. They both install and update packages from the NPM registry, with some different features available. `npx` comes with the `npm` tool, and is a way to quickly run CLI packages like `create-react-app` without having to explicitly run a separate "install this globally" command first.
  - davedx 7y ago
    Thanks for the breakdown! I find it really difficult to track everything that's going on in the react ecosystem. I realise for many people 'npx' is something that's been available for a while now but it's one of the many things I haven't had time to look at yet
leshow 7y ago
So interesting that a few years after Rust introduced the optional chaining operator, it's been filtered through the lens of many major languages out there. I think Rust was the first to do it (if you don't count Haskell's more general do-notation). Can anyone confirm that?
- jsolson 7y ago
  Swift? Or, depending on how you feel about sending a message to nil simply returning nil, Objective-C? Swift's variant is much more modern, though, as it has the ability to inline assert. https://docs.swift.org/swift-book/LanguageGuide/OptionalChaining.html https://docs.swift.org/swift-book/LanguageGuide/OptionalChai...
  - leshow 7y ago
    Rust had it before Swift did, I remember when the ? proposal came down the pipe to replace the try! macro and Swift didn't have it yet
- deleted 7y ago
  [deleted]
- rpeden 7y ago
  I think C# (and VB) had it before Rust. My memory of the timeline might be a bit off, though. I know C# and VB got the chaining operator in 2015.
- RubenSandwich 7y ago
  After some digging, I think Groovy got it first. Here is a blog post from 2009 about it: https://mrhaki.blogspot.com/2009/08/groovy-goodness-safe-navigation-to.html https://mrhaki.blogspot.com/2009/08/groovy-goodness-safe-nav....
  - leshow 7y ago
    Cool, thanks for this. Rust/Swift's variant is arguably a little different (because it works with a sum type) but I think the influence is pretty clear here.
misiti3780 7y ago
Am I the only one here that loves the idea of create-react-app but doesnt use it because it is almost impossible (or rather, was almost impossible as of a few months ago) to utilize features in webpack etc. The whole idea of "you need to eject" and can only eject one time to install a package that allowed me to use JSX If/Else statements [1] turned me off to the whole thing. Now I have a custom project and just create new ones with cookiecutter Im open to being wrong here, but the experience kinda sucked IMO. [1]https://github.com/AlexGilleran/jsx-control-statements https://github.com/AlexGilleran/jsx-control-statements
- pcmaffey 7y ago
  Use craco. https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco I needed it to get CRA working in a lerna/yarn workspaces monorepo. Super impressed with how easy config is.
  - misiti3780 7y ago
    this is exactly what i was looking for, thank you!
- zuck9 7y ago
  You can use https://github.com/timarney/react-app-rewired https://github.com/timarney/react-app-rewired to override anything in the default CRA config
  - sli 7y ago
    I don't think this works on CRA 3 and it's development has slowed a lot. craco (listed in the alternatives) supports CRA 3.
    - zuck9 7y ago
      I've been using it for a while with CRA 3 / react-scripts 3.2 Works fine for overriding Webpack config at least.
- 7y ago

114 points by revicon 7y ago

tomashubelbauer 7y ago

Isn't it odd that the removal of --typescript in favor of --template isn't considered a breaking change?

acemarke 7y ago
It's not removed, it's just being deprecated. I would assume it would only be removed in 4.0: > For TypeScript users, we're deprecating --typescript in favour of --template typescript.
Vinnl 7y ago
You only run that when starting a new project, right? So no existing projects would break when it's actually removed, because they'd never run it again.

JMTQp8lwXL 7y ago

Question for people who use these CLIs to start projects: Since there's so much prebaked functionality in the generated code, do you get distracted by it, when working on it? The CLI probably enables a few dozen features, of which you might use a handful of. So there's all these files and configuration code in your project that is never touched/used. I imagine it's a lot of white noise. Whenever I start new projects, I cleanroom start with an empty git repo. Every line, in every file, has a purpose. (With time, there is some slippage. A feature could get removed, and some code doesn't get eliminated that should, for example). But all in all, the vast majority of the code there serves a purpose. Little to no mental energy is spent worrying about side effects or filtering through code that's not only not relevant to my current work, but has no present value in the project at all. I take a functional style, with the above, to allow myself to really be able to focus on my work. I sometimes feel alone in this approach, but it works for me and I see it's benefits. I place a big premium on clarity.

SenHeng 7y ago
I typically start such a new project by cloning from a boiler plate repo that I created myself. I find those easier to use than CRA.
- rajatsharma91 7y ago
  That's a good strategy, I occasionally use that too, but a better strategy is to keep isolating often repeated functionality in your project and turn them into library packages, so you can simply add them as a dependency from now on. This way, you boilerplate becomes smaller over time or you can even start from scratch easily.
  - jholman 7y ago
    The repeated functionality that belongs in a boilerplate is literally all that CRA does. That's what makes a boilerplate a boilerplate.
- JMTQp8lwXL 7y ago
  I have my own babel+webpack+etc repo I clone for mini-things I want to dig into (e.g., how does "tool x" work?) and I can freely explore learning that tool, without clouding my production important code base. I then transport those learnings back, and the implementation is more refined, since it's clearly written by somehow who knows how to effectively use Tool X, without haphazardly throwing it around.
- Keats 7y ago
  I do the same. I find it much easier to understand and I've always needed to modify the config anyway. I wrote about my own boilerplate in https://www.vincentprouillet.com/blog/react-typescript-webpack-1/ https://www.vincentprouillet.com/blog/react-typescript-webpa... and the Webpack config is like 75 lines. It could work with Vue or anything else just as well. My guess is people still think Webpack is hard to configure despite that being quite simple now.
- 52-6F-62 7y ago
  I do the exact same. I find this is especially important where license and dependency management is a concern.

cageface 7y ago

I think a lot of people have been waiting for this in order to start using the new optional chaining and nullish coalescing operators. Thanks to the Typescript and CRA teams for making this happen. This will be a nice quality of life enhancement.

davedx 7y ago

Hmm. I’m a frequent user of cra but this release reads quite confusing. What are templates and why do I need them? Why are there 3 different package tools used (npx, npm, yarn)? What is all that babel config for? I have to be honest, the main reason I use cra is so that stuff is abstracted away, and this release looks like a lot of it is starting to “spill back out”. Don’t want this to be purely negative though. I am a huge fan of cra overall and it has helped me immensely with setting up new projects and prototyping. Just hope the core simplicity will stay.

acemarke 7y ago
CRA's default template gives you several files in `/src`. In the default template, most of those files are intended as examples: - `index.js` is required as the entry point for the app - `App.js` is the main app component - `App.test.js` shows you can write a test for a component - `App.css` shows you can import CSS files directly into the JS to have it included in the output You can begin editing those files, or just delete all but `index.js` and start writing your own. Many folks who have used CRA will just immediately delete those. Beyond that, some folks have forked the `react-scripts` package just to set up a different project source template. Adding an option to specify a template means that other folks can now publish their own CRA-compatible project source templates and have them work with CRA right away. For example, I'm a Redux maintainer, and we could create a CRA template that already has a dependency on Redux (or our new Redux Toolkit package), all set up and ready to go without the user having to manually install them. The different package tools mentioned in the release notes serve different purposes. `npm` and `yarn` are competing JS package managers. They both install and update packages from the NPM registry, with some different features available. `npx` comes with the `npm` tool, and is a way to quickly run CLI packages like `create-react-app` without having to explicitly run a separate "install this globally" command first.
- davedx 7y ago
  Thanks for the breakdown! I find it really difficult to track everything that's going on in the react ecosystem. I realise for many people 'npx' is something that's been available for a while now but it's one of the many things I haven't had time to look at yet

leshow 7y ago

So interesting that a few years after Rust introduced the optional chaining operator, it's been filtered through the lens of many major languages out there. I think Rust was the first to do it (if you don't count Haskell's more general do-notation). Can anyone confirm that?

jsolson 7y ago
Swift? Or, depending on how you feel about sending a message to nil simply returning nil, Objective-C? Swift's variant is much more modern, though, as it has the ability to inline assert. https://docs.swift.org/swift-book/LanguageGuide/OptionalChaining.html https://docs.swift.org/swift-book/LanguageGuide/OptionalChai...
- leshow 7y ago
  Rust had it before Swift did, I remember when the ? proposal came down the pipe to replace the try! macro and Swift didn't have it yet
deleted 7y ago
[deleted]
rpeden 7y ago
I think C# (and VB) had it before Rust. My memory of the timeline might be a bit off, though. I know C# and VB got the chaining operator in 2015.
RubenSandwich 7y ago
After some digging, I think Groovy got it first. Here is a blog post from 2009 about it: https://mrhaki.blogspot.com/2009/08/groovy-goodness-safe-navigation-to.html https://mrhaki.blogspot.com/2009/08/groovy-goodness-safe-nav....
- leshow 7y ago
  Cool, thanks for this. Rust/Swift's variant is arguably a little different (because it works with a sum type) but I think the influence is pretty clear here.

misiti3780 7y ago

Am I the only one here that loves the idea of create-react-app but doesnt use it because it is almost impossible (or rather, was almost impossible as of a few months ago) to utilize features in webpack etc. The whole idea of "you need to eject" and can only eject one time to install a package that allowed me to use JSX If/Else statements [1] turned me off to the whole thing. Now I have a custom project and just create new ones with cookiecutter Im open to being wrong here, but the experience kinda sucked IMO. [1]https://github.com/AlexGilleran/jsx-control-statements https://github.com/AlexGilleran/jsx-control-statements

pcmaffey 7y ago
Use craco. https://github.com/gsoft-inc/craco https://github.com/gsoft-inc/craco I needed it to get CRA working in a lerna/yarn workspaces monorepo. Super impressed with how easy config is.
- misiti3780 7y ago
  this is exactly what i was looking for, thank you!
zuck9 7y ago
You can use https://github.com/timarney/react-app-rewired https://github.com/timarney/react-app-rewired to override anything in the default CRA config
- sli 7y ago
  I don't think this works on CRA 3 and it's development has slowed a lot. craco (listed in the alternatives) supports CRA 3.
  - zuck9 7y ago
    I've been using it for a while with CRA 3 / react-scripts 3.2 Works fine for overriding Webpack config at least.
7y ago