3 ms·

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

by 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
- darekkay 7y ago
  I am using redux-starter-kit in one of my projects and I was curious about the "Redux Toolkit" package you mentioned. I have somehow missed the change of name, but I find it more fitting now. Highly recommended, even for experienced Redux users.
  - acemarke 7y ago
    Yeah, we changed the name from "Redux Starter Kit" to "Redux Toolkit" because folks were misinterpreting the word "Starter" to mean that it was a CLI tool like CRA, or that it was only good for beginners. Didn't want the churn, especially since it was after RSK had hit 1.0, but we had enough people telling us "I didn't even look at it because of the word 'Starter' in the name" that it was clear that had to change. Fortunately, the feedback on the name change has been almost universally positive. And yes, RTK is intended to be useful for both new and experienced Redux users [0], and we're now recommending it as the default standard way to write Redux logic [1]. See the RTK v1.0.4 release notes [2] for the details on the name change. [0] https://redux-toolkit.js.org/introduction/quick-start https://redux-toolkit.js.org/introduction/quick-start [1] https://redux.js.org/style-guide/style-guide#use-redux-toolkit-for-writing-redux-logic https://redux.js.org/style-guide/style-guide#use-redux-toolk... [2] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.0.4 https://github.com/reduxjs/redux-toolkit/releases/tag/v1.0.4
    - cercatrova 7y ago
      React Toolkit is so good, I've been following the advanced tutorial with TypeScript and it makes Redux so much cleaner. Thank you!
chrisweekly 7y ago
I hear you, but FWIW CRA continues to do a pretty admirable job hiding the complexity. I think it's fair to say that the 3 tools you referenced by name are elementary / required knowledge before working on a Node-based project, and it'd be impossible (or crazy) for CRA to try to abstract them away: `yarn` is a generally superior alternative to `npm`. `npx` is a convenient alternative to globally-installed packages.
- shantly 7y ago
  > `yarn` is a generally superior alternative to `npm`. I’m about 18 months out from last using it, but people were saying this then and it was, in fact, full of bugs and missing features. The company I was at kept starting projects with it because it was trendy, then switching to NPM when we tried to use a feature yarn didn’t have or lost an hour debugging some problem that turned out to be yarn-induced breakage. This was the consistent experience of about a dozen developers across several projects, most of whom were very enthusiastic about yarn, at first. Maybe it’s much better now but, again, people have been saying this since it first came out and if it’s true, it’s a recent development.
  - ivankolev 7y ago
    I have the opposite experience, for our project once we moved to yarn it just works, we have not touched the config in close to a year.
    - shantly 7y ago
      I recall running into: - Messing up certain cases of dependency resolution such that you'd get a different version than NPM would give you. - Something involving not checking paths they should have been, that caused brokenness. - Local package problems of several sorts—really any 1%-of-users-or-lower use case, and I'd guess "just fetch some packages from the NPM servers" is the sole use case over 1%, seemed fairly likely to have problems. - All of the above and more sometimes causing a dependency that worked under npm to fail with misleading error messages due to bad interactions between that package and yarn. There were more but I don't remember all of them. My impression was that they implemented half the features of npm, did way fewer correctness and safety checks, crowed about how fast they were, and everyone crowned it as a superior drop-in replacement for npm literally years before that would be justified. Mind I have no love for npm and don't much care what the command I run is called or who made it, I just repeatedly saw projects start on yarn then hit a silly problem the simplest fix for which was "use npm", while people were running around shit-talking npm and acting like yarn was some kind of miracle. [EDIT] our projects were node, React, and React Native. I'd definitely believe it's possible use Yarn and never hit this if you don't happen to use a package that's broken in it and has only been tested under npm, or happen to step on one of the landmines, and maybe it actually is totally fine now, I just know people were claiming it already was and sticking their fingers in their ears when you told them otherwise back when it absolutely was not a suitable npm replacement yet.

by davedx 7y ago

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
darekkay 7y ago
I am using redux-starter-kit in one of my projects and I was curious about the "Redux Toolkit" package you mentioned. I have somehow missed the change of name, but I find it more fitting now. Highly recommended, even for experienced Redux users.
- acemarke 7y ago
  Yeah, we changed the name from "Redux Starter Kit" to "Redux Toolkit" because folks were misinterpreting the word "Starter" to mean that it was a CLI tool like CRA, or that it was only good for beginners. Didn't want the churn, especially since it was after RSK had hit 1.0, but we had enough people telling us "I didn't even look at it because of the word 'Starter' in the name" that it was clear that had to change. Fortunately, the feedback on the name change has been almost universally positive. And yes, RTK is intended to be useful for both new and experienced Redux users [0], and we're now recommending it as the default standard way to write Redux logic [1]. See the RTK v1.0.4 release notes [2] for the details on the name change. [0] https://redux-toolkit.js.org/introduction/quick-start https://redux-toolkit.js.org/introduction/quick-start [1] https://redux.js.org/style-guide/style-guide#use-redux-toolkit-for-writing-redux-logic https://redux.js.org/style-guide/style-guide#use-redux-toolk... [2] https://github.com/reduxjs/redux-toolkit/releases/tag/v1.0.4 https://github.com/reduxjs/redux-toolkit/releases/tag/v1.0.4
  - cercatrova 7y ago
    React Toolkit is so good, I've been following the advanced tutorial with TypeScript and it makes Redux so much cleaner. Thank you!

chrisweekly 7y ago

I hear you, but FWIW CRA continues to do a pretty admirable job hiding the complexity. I think it's fair to say that the 3 tools you referenced by name are elementary / required knowledge before working on a Node-based project, and it'd be impossible (or crazy) for CRA to try to abstract them away: `yarn` is a generally superior alternative to `npm`. `npx` is a convenient alternative to globally-installed packages.

shantly 7y ago
> `yarn` is a generally superior alternative to `npm`. I’m about 18 months out from last using it, but people were saying this then and it was, in fact, full of bugs and missing features. The company I was at kept starting projects with it because it was trendy, then switching to NPM when we tried to use a feature yarn didn’t have or lost an hour debugging some problem that turned out to be yarn-induced breakage. This was the consistent experience of about a dozen developers across several projects, most of whom were very enthusiastic about yarn, at first. Maybe it’s much better now but, again, people have been saying this since it first came out and if it’s true, it’s a recent development.
- ivankolev 7y ago
  I have the opposite experience, for our project once we moved to yarn it just works, we have not touched the config in close to a year.
  - shantly 7y ago
    I recall running into: - Messing up certain cases of dependency resolution such that you'd get a different version than NPM would give you. - Something involving not checking paths they should have been, that caused brokenness. - Local package problems of several sorts—really any 1%-of-users-or-lower use case, and I'd guess "just fetch some packages from the NPM servers" is the sole use case over 1%, seemed fairly likely to have problems. - All of the above and more sometimes causing a dependency that worked under npm to fail with misleading error messages due to bad interactions between that package and yarn. There were more but I don't remember all of them. My impression was that they implemented half the features of npm, did way fewer correctness and safety checks, crowed about how fast they were, and everyone crowned it as a superior drop-in replacement for npm literally years before that would be justified. Mind I have no love for npm and don't much care what the command I run is called or who made it, I just repeatedly saw projects start on yarn then hit a silly problem the simplest fix for which was "use npm", while people were running around shit-talking npm and acting like yarn was some kind of miracle. [EDIT] our projects were node, React, and React Native. I'd definitely believe it's possible use Yarn and never hit this if you don't happen to use a package that's broken in it and has only been tested under npm, or happen to step on one of the landmines, and maybe it actually is totally fine now, I just know people were claiming it already was and sticking their fingers in their ears when you told them otherwise back when it absolutely was not a suitable npm replacement yet.