New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

General feedback #11

Closed
gaearon opened this Issue Jul 17, 2016 · 152 comments

Comments

Projects
None yet
@gaearon
Member

gaearon commented Jul 17, 2016

Let’s use this thread for a general discussion.

Does the flow feel good?
Did we pick the right plugins, presets, and loaders?
Do you see areas for improvement?

This project is in a very early stage so there’s plenty of all hanging fruit if you’d like to make React experience better.

Thanks for taking a look at this project!

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 17, 2016

Member

cc @insin @mxstbr @eanplatter @ericclemmons, thank you so much for your time & ideas

Member

gaearon commented Jul 17, 2016

cc @insin @mxstbr @eanplatter @ericclemmons, thank you so much for your time & ideas

@ericclemmons

This comment has been minimized.

Show comment
Hide comment
@ericclemmons

ericclemmons Jul 17, 2016

Should we encourage or support something like nvm? Or will we specify a minimum version of Node that we can test against to ensure consistent behavior/performance?

ericclemmons commented Jul 17, 2016

Should we encourage or support something like nvm? Or will we specify a minimum version of Node that we can test against to ensure consistent behavior/performance?

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 17, 2016

Member

I'd add node >= 4 to engines. The CLI script actually already checks against this field (we took it from RN).

Member

gaearon commented Jul 17, 2016

I'd add node >= 4 to engines. The CLI script actually already checks against this field (we took it from RN).

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 17, 2016

Member

We definitely want to support n / nvm.

Member

gaearon commented Jul 17, 2016

We definitely want to support n / nvm.

@eanplatter

This comment has been minimized.

Show comment
Hide comment
@eanplatter

eanplatter Jul 17, 2016

Contributor

I'd be interested to hear what people thought about eliminating 100% of the boilerplate code. We tried to do this we enclave but made up for it with a small amount of configuration. (telling enclave where to find the index.html / React entry point).

@gaearon I know you mentioned not wanting to have the user configure anything, so I am thinking more of an implicit kind of thing.

While it might not be totally pragmatic to hide the index.html file, it might make sense to just let the user know that they need to create a Main.js file in the root of their app. (similar to something like Elm).

While boilerplate is a helpful way to show a new user how to get started, it can be hard for beginners to know what they can touch.

Also, sometimes when a user is using something with boilerplate, it can make community resources (like tutorials) a bit harder to grok because they're having to dance around code written by the tool.

I'm willing to be swayed either way :P but in my experience I've found that beginners appreciate the ability to understand all the code written in their application.

Contributor

eanplatter commented Jul 17, 2016

I'd be interested to hear what people thought about eliminating 100% of the boilerplate code. We tried to do this we enclave but made up for it with a small amount of configuration. (telling enclave where to find the index.html / React entry point).

@gaearon I know you mentioned not wanting to have the user configure anything, so I am thinking more of an implicit kind of thing.

While it might not be totally pragmatic to hide the index.html file, it might make sense to just let the user know that they need to create a Main.js file in the root of their app. (similar to something like Elm).

While boilerplate is a helpful way to show a new user how to get started, it can be hard for beginners to know what they can touch.

Also, sometimes when a user is using something with boilerplate, it can make community resources (like tutorials) a bit harder to grok because they're having to dance around code written by the tool.

I'm willing to be swayed either way :P but in my experience I've found that beginners appreciate the ability to understand all the code written in their application.

@keyanzhang

This comment has been minimized.

Show comment
Hide comment
@keyanzhang

keyanzhang Jul 17, 2016

Member

I was about to ask you if we want multiple scaffolds/boilerplates, but I'm not sure if that aligns with the design decision here. Maintaining multiple scaffolds is also an overhead. As a solution, I thought about this a while ago and I imagined a npm init-like interactive cli initialization experience -- something like:

Do you want to use CSS Modules? (Y/n)

My motivation behind this is, CSS Modules is popularly adopted and a lot of people would want to use it in their project. But if I'll need to "graduate" in order to add the config, then it feels more like a yet-another boilerplate again. Do you think this fits with our design goal?

Member

keyanzhang commented Jul 17, 2016

I was about to ask you if we want multiple scaffolds/boilerplates, but I'm not sure if that aligns with the design decision here. Maintaining multiple scaffolds is also an overhead. As a solution, I thought about this a while ago and I imagined a npm init-like interactive cli initialization experience -- something like:

Do you want to use CSS Modules? (Y/n)

My motivation behind this is, CSS Modules is popularly adopted and a lot of people would want to use it in their project. But if I'll need to "graduate" in order to add the config, then it feels more like a yet-another boilerplate again. Do you think this fits with our design goal?

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 17, 2016

Member

@gaearon I know you mentioned not wanting to have the user configure anything, so I am thinking more of an implicit kind of thing.

While it might not be totally pragmatic to hide the index.html file, it might make sense to just let the user know that they need to create a Main.js file in the root of their app. (similar to something like Elm).

Isn't this what we do? The location and names of index.html and src/index.js are conventional, you can't change them. The HTML file was added because people really want to customize it (for example meta tags or google analytics) but it doesn't let users change anything related to bundling.

I was about to ask you if we want multiple scaffolds/boilerplates, but I'm not sure if that aligns with the design decision here

To me, this is an explicit non-goal. People have attempted to do this, but this creates a combinatorial explosion of different incompatible tools and approaches. Beginners won't know what to choose, and advanced users will be frustrated there is not enough choice.

My motivation behind this is, CSS Modules is popularly adopted and a lot of people would want to use it in their project.

Are they good enough and easy enough to explain that we can make them a default for everyone? Every other single tool that we use, in my opinion, passes this test, but CSS Modules, as much as I like them, don't yet, in my opinion.

This is why we don't include them, and this is our philosophy in general. If we can't recommend something to everyone using React, or at least consider it a sane default while keeping in mind that for many people this is the first exposure to React, we don't add it.

Perhaps in a year CSS Modules will be obvious to everyone and we will get many requests from beginners to support them. Then we ship a codemod as yet another script that ports everyone's projects to use CSS Modules, and they become our default recommendation. I totally see this happening but not today. We need to pick our battles.

Member

gaearon commented Jul 17, 2016

@gaearon I know you mentioned not wanting to have the user configure anything, so I am thinking more of an implicit kind of thing.

While it might not be totally pragmatic to hide the index.html file, it might make sense to just let the user know that they need to create a Main.js file in the root of their app. (similar to something like Elm).

Isn't this what we do? The location and names of index.html and src/index.js are conventional, you can't change them. The HTML file was added because people really want to customize it (for example meta tags or google analytics) but it doesn't let users change anything related to bundling.

I was about to ask you if we want multiple scaffolds/boilerplates, but I'm not sure if that aligns with the design decision here

To me, this is an explicit non-goal. People have attempted to do this, but this creates a combinatorial explosion of different incompatible tools and approaches. Beginners won't know what to choose, and advanced users will be frustrated there is not enough choice.

My motivation behind this is, CSS Modules is popularly adopted and a lot of people would want to use it in their project.

Are they good enough and easy enough to explain that we can make them a default for everyone? Every other single tool that we use, in my opinion, passes this test, but CSS Modules, as much as I like them, don't yet, in my opinion.

This is why we don't include them, and this is our philosophy in general. If we can't recommend something to everyone using React, or at least consider it a sane default while keeping in mind that for many people this is the first exposure to React, we don't add it.

Perhaps in a year CSS Modules will be obvious to everyone and we will get many requests from beginners to support them. Then we ship a codemod as yet another script that ports everyone's projects to use CSS Modules, and they become our default recommendation. I totally see this happening but not today. We need to pick our battles.

@insin

This comment has been minimized.

Show comment
Hide comment
@insin

insin Jul 18, 2016

Contributor

Likely first issues:

"Where's the hot reloading?"

One of the issues opened on the same day reactpack was posted on Show HN was related to not using the default ESLint presets they chose - how easy is it to disable it or use your own with the current setup? Code style can be a controversial topic, even if people have specifically asked for more opinions.

Contributor

insin commented Jul 18, 2016

Likely first issues:

"Where's the hot reloading?"

One of the issues opened on the same day reactpack was posted on Show HN was related to not using the default ESLint presets they chose - how easy is it to disable it or use your own with the current setup? Code style can be a controversial topic, even if people have specifically asked for more opinions.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

We might eventually add hot reloading when it is stable enough but I don't think it should be a part of the official starter if it's hacky right now.

I do expect some people to ask for custom lint configuration but I'd rather not do it. Give in just a little, and you'll end up with a lot of configuration. It will be hard to draw the line where to say "yes" and where to say "no". React has never been opinionated so I think we have a right to release one very opinionated tool.

Member

gaearon commented Jul 18, 2016

We might eventually add hot reloading when it is stable enough but I don't think it should be a part of the official starter if it's hacky right now.

I do expect some people to ask for custom lint configuration but I'd rather not do it. Give in just a little, and you'll end up with a lot of configuration. It will be hard to draw the line where to say "yes" and where to say "no". React has never been opinionated so I think we have a right to release one very opinionated tool.

@eanplatter

This comment has been minimized.

Show comment
Hide comment
@eanplatter

eanplatter Jul 18, 2016

Contributor

I do expect some people to ask for custom lint configuration but I'd rather not do it.

What is your thinking behind adding linting to begin with? It might make sense for it to be lint agnostic.

Contributor

eanplatter commented Jul 18, 2016

I do expect some people to ask for custom lint configuration but I'd rather not do it.

What is your thinking behind adding linting to begin with? It might make sense for it to be lint agnostic.

@mxstbr

This comment has been minimized.

Show comment
Hide comment
@mxstbr

mxstbr Jul 18, 2016

Contributor

It's a nicer dev experience, and the react community is pretty set on using airbnb. Imo that's fine!

Contributor

mxstbr commented Jul 18, 2016

It's a nicer dev experience, and the react community is pretty set on using airbnb. Imo that's fine!

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

In my experience linting catches many mistakes. Beginners who are just getting started often don’t bother to configure a linter, and suffer from errors caused by simple typos.

Having control over linting also gives us the ability to introduce custom rules and potentially add API deprecations.

Member

gaearon commented Jul 18, 2016

In my experience linting catches many mistakes. Beginners who are just getting started often don’t bother to configure a linter, and suffer from errors caused by simple typos.

Having control over linting also gives us the ability to introduce custom rules and potentially add API deprecations.

@eanplatter

This comment has been minimized.

Show comment
Hide comment
@eanplatter

eanplatter Jul 18, 2016

Contributor

👍 is there a lint script in the users new project?

Contributor

eanplatter commented Jul 18, 2016

👍 is there a lint script in the users new project?

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

No, we do linting as part of both npm start and npm run build. It’s done via eslint-loader.

So the user sees something like this when they save a file:

screen shot 2016-07-18 at 13 56 25

Member

gaearon commented Jul 18, 2016

No, we do linting as part of both npm start and npm run build. It’s done via eslint-loader.

So the user sees something like this when they save a file:

screen shot 2016-07-18 at 13 56 25

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

If the project doesn’t crash, those warnings also show up in the console:

screen shot 2016-07-18 at 13 57 31

Member

gaearon commented Jul 18, 2016

If the project doesn’t crash, those warnings also show up in the console:

screen shot 2016-07-18 at 13 57 31

@eanplatter

This comment has been minimized.

Show comment
Hide comment
@eanplatter

eanplatter Jul 18, 2016

Contributor

I guess they can always eject if they want to configure things themselves.

Contributor

eanplatter commented Jul 18, 2016

I guess they can always eject if they want to configure things themselves.

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 18, 2016

Contributor

I found the linting frustrating when I tried starting here and following along on other tutorials that don't follow the linting rules. Some of the rules like no-var and semi are in conflict with a lot of our own example code. What do you think about having lint hidden behind something like npm run lint?

In my experience of asking people, most folks do not use a linter. And most folks who say they use "airbnb lint" have actually customized it a bit.

Contributor

lacker commented Jul 18, 2016

I found the linting frustrating when I tried starting here and following along on other tutorials that don't follow the linting rules. Some of the rules like no-var and semi are in conflict with a lot of our own example code. What do you think about having lint hidden behind something like npm run lint?

In my experience of asking people, most folks do not use a linter. And most folks who say they use "airbnb lint" have actually customized it a bit.

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 18, 2016

Contributor

So right after I ran create-react-app, it had a file:/// dependency in the package.json. Is that supposed to happen when this is live, or is that an artifact of running it from npm run create-react-app? If it actually creates a project with a dependency on the creation tool which lives outside the repo, then I can't collaborate with other people on it.

Contributor

lacker commented Jul 18, 2016

So right after I ran create-react-app, it had a file:/// dependency in the package.json. Is that supposed to happen when this is live, or is that an artifact of running it from npm run create-react-app? If it actually creates a project with a dependency on the creation tool which lives outside the repo, then I can't collaborate with other people on it.

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 18, 2016

Contributor

Also, I ejected pretty soon. Why not just eject right away? - I did not see any advantage of using the un-ejected version. The tool is already creating some boilerplate for me, it might as well create more.

Contributor

lacker commented Jul 18, 2016

Also, I ejected pretty soon. Why not just eject right away? - I did not see any advantage of using the un-ejected version. The tool is already creating some boilerplate for me, it might as well create more.

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 18, 2016

Contributor

Also, how about rendering to a specific element rather than doing const rootEl = document.createElement('div'); document.body.appendChild(rootEl); render(<App />, rootEl);

That way you don't need to muck around with js code if you need to do something like add some custom html to your app.

Contributor

lacker commented Jul 18, 2016

Also, how about rendering to a specific element rather than doing const rootEl = document.createElement('div'); document.body.appendChild(rootEl); render(<App />, rootEl);

That way you don't need to muck around with js code if you need to do something like add some custom html to your app.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

So right after I ran create-react-app, it had a file:/// dependency in the package.json. Is that supposed to happen when this is live, or is that an artifact of running it from npm run create-react-app? If it actually creates a project with a dependency on the creation tool which lives outside the repo, then I can't collaborate with other people on it.

No, this is because packages are not on npm yet.
In the “normal” npm flow, you’d get a regular dependency.

Member

gaearon commented Jul 18, 2016

So right after I ran create-react-app, it had a file:/// dependency in the package.json. Is that supposed to happen when this is live, or is that an artifact of running it from npm run create-react-app? If it actually creates a project with a dependency on the creation tool which lives outside the repo, then I can't collaborate with other people on it.

No, this is because packages are not on npm yet.
In the “normal” npm flow, you’d get a regular dependency.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

Also, I ejected pretty soon. Why not just eject right away? - I did not see any advantage of using the un-ejected version. The tool is already creating some boilerplate for me, it might as well create more.

The number one complaint I heard about “JavaScript fatigue” is that there are tons of dependencies in package.json and you aren’t sure how/when to update them because they are often incompatible, each requires maintaining its own config, releases breaking changes, etc.

https://twitter.com/thomasfuchs/status/708675139253174273

Here is a good example of an issue like this. Somebody was trying to follow a “React for Beginners” starter guide but updated Babel and got a weird error: babel/babel-loader#255. If you hunt around, you’ll find hundreds of issues like this across different boilerplate projects, React, Redux, Babel, ESLint, etc.

If you’re comfortable configuring ESLint, Babel, and Webpack yourself, you can indeed eject right away. This is the level of utility already provided by the popular boilerplate projects. However, if you’re not used to those tools, having a bunch of complicated configs in your folder is very intimidating. I’m trying to provide a better experience for people who are just getting started with React and don’t want to customize anything—rather, they want somebody to hold their hand while they’re writing their first component. And providing the escape hatch turns it from a toy into a real tool.

Another intention is that we keep improving the default set of plugins over time. For example, we might switch to Webpack 2, or Babel 7, or ESLint 3, or whatever, at our own pace, at the same time ensuring they all work great together. This is something a user can’t easily do if they’re on their own unless they have an extensive knowledge of all those tools.

Member

gaearon commented Jul 18, 2016

Also, I ejected pretty soon. Why not just eject right away? - I did not see any advantage of using the un-ejected version. The tool is already creating some boilerplate for me, it might as well create more.

The number one complaint I heard about “JavaScript fatigue” is that there are tons of dependencies in package.json and you aren’t sure how/when to update them because they are often incompatible, each requires maintaining its own config, releases breaking changes, etc.

https://twitter.com/thomasfuchs/status/708675139253174273

Here is a good example of an issue like this. Somebody was trying to follow a “React for Beginners” starter guide but updated Babel and got a weird error: babel/babel-loader#255. If you hunt around, you’ll find hundreds of issues like this across different boilerplate projects, React, Redux, Babel, ESLint, etc.

If you’re comfortable configuring ESLint, Babel, and Webpack yourself, you can indeed eject right away. This is the level of utility already provided by the popular boilerplate projects. However, if you’re not used to those tools, having a bunch of complicated configs in your folder is very intimidating. I’m trying to provide a better experience for people who are just getting started with React and don’t want to customize anything—rather, they want somebody to hold their hand while they’re writing their first component. And providing the escape hatch turns it from a toy into a real tool.

Another intention is that we keep improving the default set of plugins over time. For example, we might switch to Webpack 2, or Babel 7, or ESLint 3, or whatever, at our own pace, at the same time ensuring they all work great together. This is something a user can’t easily do if they’re on their own unless they have an extensive knowledge of all those tools.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

Also, how about rendering to a specific element rather than doing const rootEl = document.createElement('div'); document.body.appendChild(rootEl); render(, rootEl);

That way you don't need to muck around with js code if you need to do something like add some custom html to your app.

I’m not sure what you mean. What kind of custom HTML? Why not do it in a React component instead? To be clear, this tool is targeted towards people creating greenfield single-page apps. React already has a good integration story; we just want to fix the “start from scratch” story.

We can change it for sure, but I’d like to better understand the use case you have in mind.

Member

gaearon commented Jul 18, 2016

Also, how about rendering to a specific element rather than doing const rootEl = document.createElement('div'); document.body.appendChild(rootEl); render(, rootEl);

That way you don't need to muck around with js code if you need to do something like add some custom html to your app.

I’m not sure what you mean. What kind of custom HTML? Why not do it in a React component instead? To be clear, this tool is targeted towards people creating greenfield single-page apps. React already has a good integration story; we just want to fix the “start from scratch” story.

We can change it for sure, but I’d like to better understand the use case you have in mind.

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 18, 2016

Contributor

I was thinking adding other libraries like analytics, where you often have noobs following some instructions of how to modify their html. It's a bit simpler to figure out what's happening if there is a div already in index.html that your app gets rendered to.

Contributor

lacker commented Jul 18, 2016

I was thinking adding other libraries like analytics, where you often have noobs following some instructions of how to modify their html. It's a bit simpler to figure out what's happening if there is a div already in index.html that your app gets rendered to.

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 18, 2016

Contributor

Another intention is that we keep improving the default set of plugins over time. For example, we might switch to Webpack 2, or Babel 7, or ESLint 3, or whatever, at our own pace, at the same time ensuring they all work great together.

So the idea is that someone would be able to just upgrade their create-react-app-scripts dependency, and then they could get more modern stuff? That seems cool. If you can't upgrade this set of scripts, though, then it seems equivalent to saying "heres some boilerplate, just never update it".

Contributor

lacker commented Jul 18, 2016

Another intention is that we keep improving the default set of plugins over time. For example, we might switch to Webpack 2, or Babel 7, or ESLint 3, or whatever, at our own pace, at the same time ensuring they all work great together.

So the idea is that someone would be able to just upgrade their create-react-app-scripts dependency, and then they could get more modern stuff? That seems cool. If you can't upgrade this set of scripts, though, then it seems equivalent to saying "heres some boilerplate, just never update it".

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

I found the linting frustrating when I tried starting here and following along on other tutorials that don't follow the linting rules. Some of the rules like no-var and semi are in conflict with a lot of our own example code. What do you think about having lint hidden behind something like npm run lint?

To be honest I would rather choose our own subset of rules that is more flexible about code style than remove linting altogether from the flow. In my experience of replying to issues on React and Redux repo, people often do mistakes that would be caught by a linter. A separate npm run lint wouldn’t help them because they wouldn’t run it.

In my experience of asking people, most folks do not use a linter. And most folks who say they use "airbnb lint" have actually customized it a bit.

I think there is a middle ground here: beginners and people who didn’t bother to use a linter because it is too complicated to set it up (e.g. ESLint didn’t work with ES6 until recently, babel-eslint integration was often buggy while it was necessary, etc).

Maybe my bet is off. I don’t know. But I feel like it’s better to start enforcing the lint, and later loosen it up, than start relaxed and later tighten it up. We can teach people that it is an opinionated tool, and this is what we think is the best way to start getting up to speed with React.

We use vars in the docs because our docs assume ES5. This is a different and separate issue: we do intend to update them, but we need a plausible “getting started” experience that includes ES6 for this. So it’s a bit of a chicken-and-egg problem.

I was thinking adding other libraries like analytics, where you often have noobs following some instructions of how to modify their html. It's a bit simpler to figure out what's happening if there is a div already in index.html that your app gets rendered to.

Perhaps. I thought the comment in index.html helps, does it not?

So the idea is that someone would be able to just upgrade their create-react-app-scripts dependency, and then they could get more modern stuff? That seems cool. If you can't upgrade this set of scripts, though, then it seems equivalent to saying "heres some boilerplate, just never update it".

Yes, the idea is that we release versions once in a while that track what’s going on in the ecosystem and put the best stable things together.

Member

gaearon commented Jul 18, 2016

I found the linting frustrating when I tried starting here and following along on other tutorials that don't follow the linting rules. Some of the rules like no-var and semi are in conflict with a lot of our own example code. What do you think about having lint hidden behind something like npm run lint?

To be honest I would rather choose our own subset of rules that is more flexible about code style than remove linting altogether from the flow. In my experience of replying to issues on React and Redux repo, people often do mistakes that would be caught by a linter. A separate npm run lint wouldn’t help them because they wouldn’t run it.

In my experience of asking people, most folks do not use a linter. And most folks who say they use "airbnb lint" have actually customized it a bit.

I think there is a middle ground here: beginners and people who didn’t bother to use a linter because it is too complicated to set it up (e.g. ESLint didn’t work with ES6 until recently, babel-eslint integration was often buggy while it was necessary, etc).

Maybe my bet is off. I don’t know. But I feel like it’s better to start enforcing the lint, and later loosen it up, than start relaxed and later tighten it up. We can teach people that it is an opinionated tool, and this is what we think is the best way to start getting up to speed with React.

We use vars in the docs because our docs assume ES5. This is a different and separate issue: we do intend to update them, but we need a plausible “getting started” experience that includes ES6 for this. So it’s a bit of a chicken-and-egg problem.

I was thinking adding other libraries like analytics, where you often have noobs following some instructions of how to modify their html. It's a bit simpler to figure out what's happening if there is a div already in index.html that your app gets rendered to.

Perhaps. I thought the comment in index.html helps, does it not?

So the idea is that someone would be able to just upgrade their create-react-app-scripts dependency, and then they could get more modern stuff? That seems cool. If you can't upgrade this set of scripts, though, then it seems equivalent to saying "heres some boilerplate, just never update it".

Yes, the idea is that we release versions once in a while that track what’s going on in the ecosystem and put the best stable things together.

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 18, 2016

Contributor

To be honest I would rather choose our own subset of rules that is more flexible about code style than remove linting altogether from the flow.

Mmm that sounds good to me. I tried using the airbnb style on a sample app and found it was too strict for what I wanted - in particular I ended up disabling

"rules": { "arrow-body-style": 0, "new-cap": 0, "no-console": 0, "no-param-reassign": 0, "no-undef": 0, "no-useless-constructor": 0, "no-use-before-define": 0, "react/prefer-stateless-function": 0, },

Like, if we tell noobs they shouldn't use console.log, they will become sad.

I really like the idea that we can update these tools over time and thus not become dependent on eslint specifically.

Also I think it would be nice to try to use similar language presets for the default apps created by React and React Native - it'll just make it easier for anyone building or documenting a cross-environment library.

Contributor

lacker commented Jul 18, 2016

To be honest I would rather choose our own subset of rules that is more flexible about code style than remove linting altogether from the flow.

Mmm that sounds good to me. I tried using the airbnb style on a sample app and found it was too strict for what I wanted - in particular I ended up disabling

"rules": { "arrow-body-style": 0, "new-cap": 0, "no-console": 0, "no-param-reassign": 0, "no-undef": 0, "no-useless-constructor": 0, "no-use-before-define": 0, "react/prefer-stateless-function": 0, },

Like, if we tell noobs they shouldn't use console.log, they will become sad.

I really like the idea that we can update these tools over time and thus not become dependent on eslint specifically.

Also I think it would be nice to try to use similar language presets for the default apps created by React and React Native - it'll just make it easier for anyone building or documenting a cross-environment library.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

Would you like to send a PR with the ESLint rule subset you find reasonable?

Member

gaearon commented Jul 18, 2016

Would you like to send a PR with the ESLint rule subset you find reasonable?

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 18, 2016

Contributor

Sure - not fair of me to gripe without offering to fix it ;-)

Contributor

lacker commented Jul 18, 2016

Sure - not fair of me to gripe without offering to fix it ;-)

@vjeux

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Jul 18, 2016

Contributor

I was going to say, we already have Facebook eslintrc on fbjs but it seems like every single of our open source project is using a different variation:

Contributor

vjeux commented Jul 18, 2016

I was going to say, we already have Facebook eslintrc on fbjs but it seems like every single of our open source project is using a different variation:

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jul 18, 2016

Contributor

While you're at it, maybe you could add: "semi": [2, "never"] :trollface:
Sorry, someone had to say it. (But if that happened, I'd be pleased)

Contributor

kentcdodds commented Jul 18, 2016

While you're at it, maybe you could add: "semi": [2, "never"] :trollface:
Sorry, someone had to say it. (But if that happened, I'd be pleased)

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 18, 2016

Member

I think our guideline should be: let’s ship ESLint warnings that help find bugs or avoid bugs in the future.

Member

gaearon commented Jul 18, 2016

I think our guideline should be: let’s ship ESLint warnings that help find bugs or avoid bugs in the future.

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 18, 2016

Contributor

Playing around, I find myself often deleting some of the autogenerated files, because I don't want some subset of App.js, App.css, index.css, logo.png. What do you think about simplifying the autogenerated stuff to just index.html and index.js in the main folder? (No src.) The pattern where you have your index files at the root and then other stuff is in a folder is how React Native typically works, for example. (E.g. https://github.com/fbsamples/f8app ) And that pattern seems fairly common for React apps too. E.g. https://github.com/reactjs/redux/tree/master/examples/todomvc That way people can decide if they want a "src" folder or what.

Contributor

lacker commented Jul 18, 2016

Playing around, I find myself often deleting some of the autogenerated files, because I don't want some subset of App.js, App.css, index.css, logo.png. What do you think about simplifying the autogenerated stuff to just index.html and index.js in the main folder? (No src.) The pattern where you have your index files at the root and then other stuff is in a folder is how React Native typically works, for example. (E.g. https://github.com/fbsamples/f8app ) And that pattern seems fairly common for React apps too. E.g. https://github.com/reactjs/redux/tree/master/examples/todomvc That way people can decide if they want a "src" folder or what.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 19, 2016

Member

My intention was to bootstrap a project that shows:

  • How to create a component
  • How to import a component from another component
  • How to reference CSS
  • How to reference an image
  • How to render the root component to the DOM

Those are the most common questions I see about Webpack-based setups, and it is not obvious at all that you need to import CSS until you see it. So I think it’s important to explain it to people who never worked with Webpack.

If we don’t provide these, people will try adding images in local directory and expecting them to be available by paths like src='./logo.png', they will add CSS to index.html without realizing we already solve autoprefixing for them, and they will import components with named imports (import { App } from './App') while using default exports and be frustrated that this doesn’t work.

How do you think we could solve those problems without frustrating experienced users?

Member

gaearon commented Jul 19, 2016

My intention was to bootstrap a project that shows:

  • How to create a component
  • How to import a component from another component
  • How to reference CSS
  • How to reference an image
  • How to render the root component to the DOM

Those are the most common questions I see about Webpack-based setups, and it is not obvious at all that you need to import CSS until you see it. So I think it’s important to explain it to people who never worked with Webpack.

If we don’t provide these, people will try adding images in local directory and expecting them to be available by paths like src='./logo.png', they will add CSS to index.html without realizing we already solve autoprefixing for them, and they will import components with named imports (import { App } from './App') while using default exports and be frustrated that this doesn’t work.

How do you think we could solve those problems without frustrating experienced users?

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 19, 2016

Member

FWIW I’m not completely opposed to CLI flags. create-react-app my-app --template empty is fine in my book because this lets us add more official examples later to get people started with something they can run and tweak.

Member

gaearon commented Jul 19, 2016

FWIW I’m not completely opposed to CLI flags. create-react-app my-app --template empty is fine in my book because this lets us add more official examples later to get people started with something they can run and tweak.

@eanplatter

This comment has been minimized.

Show comment
Hide comment
@eanplatter

eanplatter Jul 19, 2016

Contributor

I can't help but agree, it's easy to forget how valuable it is to see first hand how to do something like reference a CSS file in a React component.

Keeping the boilerplate as minimal as possible (like it currently is) is important. Perhaps some inline comments to help dispel any questions about the generates code itself?

Contributor

eanplatter commented Jul 19, 2016

I can't help but agree, it's easy to forget how valuable it is to see first hand how to do something like reference a CSS file in a React component.

Keeping the boilerplate as minimal as possible (like it currently is) is important. Perhaps some inline comments to help dispel any questions about the generates code itself?

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 19, 2016

Member

Let’s continue this discussion (on templates) in #24.

Member

gaearon commented Jul 19, 2016

Let’s continue this discussion (on templates) in #24.

@lacker

This comment has been minimized.

Show comment
Hide comment
@lacker

lacker Jul 19, 2016

Contributor

So I am actually one of these webpack noobs, I haven't forgotten what it's like ;-)

Before using this tool I never included css and images with an import statement the way it works here. I'll admit it was helpful. I didn't realize there was "autoprefixing" going on, though. How exactly does that work? Is it just using the stuff in https://github.com/postcss/autoprefixer ? Perhaps just a brief comment explaining that would be helpful somewhere in the code.

Also, it was unclear to me whether the "src" directory is special in some way. I have used some webpack configs where you have to put everything in a certain directory, and some where it does not work that way. Is there any requirement besides the starting point being src/index.js? Like do other image / css files have to also be in the src directory? Personally I often prefer to not call the directory "src" because if you e.g. end up making a rails backend, your ruby code is also "src" and so it's confusing to call just one of your languages "src". Or for React Native.

Contributor

lacker commented Jul 19, 2016

So I am actually one of these webpack noobs, I haven't forgotten what it's like ;-)

Before using this tool I never included css and images with an import statement the way it works here. I'll admit it was helpful. I didn't realize there was "autoprefixing" going on, though. How exactly does that work? Is it just using the stuff in https://github.com/postcss/autoprefixer ? Perhaps just a brief comment explaining that would be helpful somewhere in the code.

Also, it was unclear to me whether the "src" directory is special in some way. I have used some webpack configs where you have to put everything in a certain directory, and some where it does not work that way. Is there any requirement besides the starting point being src/index.js? Like do other image / css files have to also be in the src directory? Personally I often prefer to not call the directory "src" because if you e.g. end up making a rails backend, your ruby code is also "src" and so it's confusing to call just one of your languages "src". Or for React Native.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 28, 2016

Member

@elsigh

I updated the guide: https://github.com/facebookincubator/create-react-app/blob/master/template/README.md#display-lint-output-in-the-editor

Unfortunately there’s no better way to fix it without global installs until eslint/eslint#3458 if fixed.

Member

gaearon commented Jul 28, 2016

@elsigh

I updated the guide: https://github.com/facebookincubator/create-react-app/blob/master/template/README.md#display-lint-output-in-the-editor

Unfortunately there’s no better way to fix it without global installs until eslint/eslint#3458 if fixed.

@FastNinja

This comment has been minimized.

Show comment
Hide comment
@FastNinja

FastNinja Jul 29, 2016

started for a new project but had to eject soon. reason - need to use existing huge CSS file (company wide branding styles) into HTML and could not find the way to do that.

FastNinja commented Jul 29, 2016

started for a new project but had to eject soon. reason - need to use existing huge CSS file (company wide branding styles) into HTML and could not find the way to do that.

@mxstbr

This comment has been minimized.

Show comment
Hide comment
@mxstbr

mxstbr Jul 29, 2016

Contributor

@FastNinja if #226 got merged, would that satisfy your use case?

Contributor

mxstbr commented Jul 29, 2016

@FastNinja if #226 got merged, would that satisfy your use case?

@FastNinja

This comment has been minimized.

Show comment
Hide comment
@FastNinja

FastNinja Jul 29, 2016

@mxstbr looks like yes. I will have to place CSS into static/css and it will be bundled, correct?

FastNinja commented Jul 29, 2016

@mxstbr looks like yes. I will have to place CSS into static/css and it will be bundled, correct?

@mxstbr

This comment has been minimized.

Show comment
Hide comment
@mxstbr

mxstbr Jul 29, 2016

Contributor

Well, not bundled, but you would be able reference it in your index.html:

<link rel="stylesheet" type="text/css" href="static/css/something.min.css" />
Contributor

mxstbr commented Jul 29, 2016

Well, not bundled, but you would be able reference it in your index.html:

<link rel="stylesheet" type="text/css" href="static/css/something.min.css" />
@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 29, 2016

Member

What's wrong with importing it from JS? We already have an example of src/index.css, why not put it there (or in another file you import from index.js)?

Please don't rely on referencing anything from HTML now. How that works might change (it's not currently supported officially).

Member

gaearon commented Jul 29, 2016

What's wrong with importing it from JS? We already have an example of src/index.css, why not put it there (or in another file you import from index.js)?

Please don't rely on referencing anything from HTML now. How that works might change (it's not currently supported officially).

@JacopKane

This comment has been minimized.

Show comment
Hide comment
@JacopKane

JacopKane Jul 29, 2016

I just wrote my first react app in few hours thanks to this tool. Perfect for beginners. Would love to see flux,redux etc. integrations in in the future.

JacopKane commented Jul 29, 2016

I just wrote my first react app in few hours thanks to this tool. Perfect for beginners. Would love to see flux,redux etc. integrations in in the future.

@idibidiart

This comment has been minimized.

Show comment
Hide comment
@idibidiart

idibidiart Jul 29, 2016

@JacopKane

I don't think they can pick winners and losers as far as things like Redux vs MobX vs Redux+Relay and GraphQL vs Falcor etc.

You have frameworks like Apollo that are opinionated and make it easy to get started. I would recommend going that route when you're ready.

idibidiart commented Jul 29, 2016

@JacopKane

I don't think they can pick winners and losers as far as things like Redux vs MobX vs Redux+Relay and GraphQL vs Falcor etc.

You have frameworks like Apollo that are opinionated and make it easy to get started. I would recommend going that route when you're ready.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Jul 29, 2016

Member

For now we’re trying to solve the problem of build dependencies, not the complete stack.

Member

gaearon commented Jul 29, 2016

For now we’re trying to solve the problem of build dependencies, not the complete stack.

@JacopKane

This comment has been minimized.

Show comment
Hide comment
@JacopKane

JacopKane Jul 31, 2016

@idibidiart @gaearon Thanks for the explanations

JacopKane commented Jul 31, 2016

@idibidiart @gaearon Thanks for the explanations

@wle8300

This comment has been minimized.

Show comment
Hide comment
@wle8300

wle8300 Aug 1, 2016

What do I do if a npm module needs to use Webpack's plugin "css-loader" to bundle up some css assets?

For example, react-spinkit breaks because create-react-app isn't including the css/gifs for the loading animations.

Edit: Thx for making this by the way gaeron! I second what JacopKane said. Got up and running really fast. Delightful DX.

wle8300 commented Aug 1, 2016

What do I do if a npm module needs to use Webpack's plugin "css-loader" to bundle up some css assets?

For example, react-spinkit breaks because create-react-app isn't including the css/gifs for the loading animations.

Edit: Thx for making this by the way gaeron! I second what JacopKane said. Got up and running really fast. Delightful DX.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Aug 1, 2016

Member

For example, react-spinkit breaks because create-react-app isn't including the css/gifs for the loading animations.

Can you submit an issue with a reproducing example? It works for me.

Member

gaearon commented Aug 1, 2016

For example, react-spinkit breaks because create-react-app isn't including the css/gifs for the loading animations.

Can you submit an issue with a reproducing example? It works for me.

@bjnortier

This comment has been minimized.

Show comment
Hide comment
@bjnortier

bjnortier Aug 1, 2016

Thanks for this project.

A tip for anyone reading this who is using Atom: there are at least two eslint packages, "linter-eslint" and "fast-eslint".

"linter-eslint" _doesn't_ use the global eslint as recommended in docs:

"linter-eslint will look for a version of eslint local to your project and use it if it's available. If none is found it will fall back to the version it ships with.

and it didn't work for me.

But "fast-eslint" work with the globally installed eslint, and that worked

bjnortier commented Aug 1, 2016

Thanks for this project.

A tip for anyone reading this who is using Atom: there are at least two eslint packages, "linter-eslint" and "fast-eslint".

"linter-eslint" _doesn't_ use the global eslint as recommended in docs:

"linter-eslint will look for a version of eslint local to your project and use it if it's available. If none is found it will fall back to the version it ships with.

and it didn't work for me.

But "fast-eslint" work with the globally installed eslint, and that worked

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Aug 1, 2016

Member

linter-eslint has an option for this:

screen shot 2016-08-01 at 21 23 04

Would you like to submit a PR to clarify this in the doc?

Member

gaearon commented Aug 1, 2016

linter-eslint has an option for this:

screen shot 2016-08-01 at 21 23 04

Would you like to submit a PR to clarify this in the doc?

@bjnortier

This comment has been minimized.

Show comment
Hide comment
@bjnortier

bjnortier Aug 1, 2016

Hmmm, I didn't see the global option in the plugin config, but I do now. One would think in the settings that value should be above the "Global Node Installation Path" value, which I did see.

Happy to create a PR as a hint to Atom users

bjnortier commented Aug 1, 2016

Hmmm, I didn't see the global option in the plugin config, but I do now. One would think in the settings that value should be above the "Global Node Installation Path" value, which I did see.

Happy to create a PR as a hint to Atom users

@wle8300

This comment has been minimized.

Show comment
Hide comment
@wle8300

wle8300 Aug 1, 2016

@gaearon Hm. I created a new project and installed react-spinkit... now everything's working as it ought. Haha oh wellz!

If it happens again I'll bring it up. I'm assuming I probably edited some files in some funky way. Thanks for the help!

wle8300 commented Aug 1, 2016

@gaearon Hm. I created a new project and installed react-spinkit... now everything's working as it ought. Haha oh wellz!

If it happens again I'll bring it up. I'm assuming I probably edited some files in some funky way. Thanks for the help!

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Aug 1, 2016

Member

@williamle8300 We had a fix for this in 0.2.0 so maybe that’s why.

Member

gaearon commented Aug 1, 2016

@williamle8300 We had a fix for this in 0.2.0 so maybe that’s why.

@wle8300

This comment has been minimized.

Show comment
Hide comment
@wle8300

wle8300 Aug 1, 2016

@gaeron Ohhhhhh hah. I downloaded this 10ms after it was announced. I should have npm update 'ed dat thang.

wle8300 commented Aug 1, 2016

@gaeron Ohhhhhh hah. I downloaded this 10ms after it was announced. I should have npm update 'ed dat thang.

@alvincrespo

This comment has been minimized.

Show comment
Hide comment
@alvincrespo

alvincrespo Aug 2, 2016

I am so happy to see this! This adds so much value to the React platform, I can't wait to see where you guys take it.

alvincrespo commented Aug 2, 2016

I am so happy to see this! This adds so much value to the React platform, I can't wait to see where you guys take it.

@dmitriid

This comment has been minimized.

Show comment
Hide comment
@dmitriid

dmitriid Aug 2, 2016

Also two cents on configurability.

It would probably nice to see some configurability/overridability in the future. The reason for this is quite simple: no tool is perfect for 100% of developers. There's always that pesky 1% of configuration that you want to change/update/remove/override without going through all the config files.

It should be doable for babel and eslint. Both expose settings via a .*rc file. If found in project's root directory, React scripts could merge React's .rc with the project's .rc

Webpack, however, is a weird beast (this was also mentioned in comments above). There are several projects (webpack-merge, webpack-config-merger etc.) that attempt this. But this probably deserves a proper separate discussion.


Also: can we erect a monument to honour the creators of create-react-app? I'm deadly serious.

dmitriid commented Aug 2, 2016

Also two cents on configurability.

It would probably nice to see some configurability/overridability in the future. The reason for this is quite simple: no tool is perfect for 100% of developers. There's always that pesky 1% of configuration that you want to change/update/remove/override without going through all the config files.

It should be doable for babel and eslint. Both expose settings via a .*rc file. If found in project's root directory, React scripts could merge React's .rc with the project's .rc

Webpack, however, is a weird beast (this was also mentioned in comments above). There are several projects (webpack-merge, webpack-config-merger etc.) that attempt this. But this probably deserves a proper separate discussion.


Also: can we erect a monument to honour the creators of create-react-app? I'm deadly serious.

@HintikkaKimmo

This comment has been minimized.

Show comment
Hide comment
@HintikkaKimmo

HintikkaKimmo Aug 3, 2016

This might be a stupid question, but I just started with React something with the starter app generated with create-app-react confuses me. And it's also feedback that readme should have section to explain what different parts do for example should you CSS be loaded on index.css or app.css for example.

Where is the root component or actually how the index.js gets mounted to <div class="root"></div> in that I see in the index.html file?

I would expect that index.js should be root.js or export component to do that or have I understood something completely wrong?

HintikkaKimmo commented Aug 3, 2016

This might be a stupid question, but I just started with React something with the starter app generated with create-app-react confuses me. And it's also feedback that readme should have section to explain what different parts do for example should you CSS be loaded on index.css or app.css for example.

Where is the root component or actually how the index.js gets mounted to <div class="root"></div> in that I see in the index.html file?

I would expect that index.js should be root.js or export component to do that or have I understood something completely wrong?

@wle8300

This comment has been minimized.

Show comment
Hide comment
@wle8300

wle8300 Aug 3, 2016

Did you follow the "Installation" guide on the README?

Take a look at the index.js file. That's where the mounting happens.

wle8300 commented Aug 3, 2016

Did you follow the "Installation" guide on the README?

Take a look at the index.js file. That's where the mounting happens.

@wle8300

This comment has been minimized.

Show comment
Hide comment
@wle8300

wle8300 Aug 3, 2016

Did you follow the "installation" guide on the github readme?

If you did look in the src folder. The relevant file you're looking for are

Index.html
Index.js
App.hs

On Aug 3, 2016, at 3:20 AM, Kimmo Hintikka notifications@github.com wrote:

This might be a stupid question, but I just started with React something with the starter app generated with create-app-react confuses me. And it's also feedback that readme should have section to explain what different parts do for example should you CSS be loaded on index.css or app.css for example.

Where is the root component or actually how the index.js gets mounted to

in that I see in the index.html file?

I would expect that index.js should be root.js or export component to do that or have I understood something completely wrong?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

wle8300 commented Aug 3, 2016

Did you follow the "installation" guide on the github readme?

If you did look in the src folder. The relevant file you're looking for are

Index.html
Index.js
App.hs

On Aug 3, 2016, at 3:20 AM, Kimmo Hintikka notifications@github.com wrote:

This might be a stupid question, but I just started with React something with the starter app generated with create-app-react confuses me. And it's also feedback that readme should have section to explain what different parts do for example should you CSS be loaded on index.css or app.css for example.

Where is the root component or actually how the index.js gets mounted to

in that I see in the index.html file?

I would expect that index.js should be root.js or export component to do that or have I understood something completely wrong?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@dipetersen

This comment has been minimized.

Show comment
Hide comment
@dipetersen

dipetersen Aug 3, 2016

I have somewhat of a weird request/issue. I develop applications hosted on Office365 or SharePoint. I'm trying to develop a single page app using React, hosted in a SharePoint site. My problem comes with the path references in the compiled build. Right now, it is all relative to the build folder. If I copy the build folder to my SharePoint site and make a reference to index.html, it can't find the included files because all the references are relative to the root of the web. In my normal deployment I put these files into a path /SiteAssets/build/. I have been successful manually changing the path references but it would be nice to be able to set this path before the build command so all references were correct.

dipetersen commented Aug 3, 2016

I have somewhat of a weird request/issue. I develop applications hosted on Office365 or SharePoint. I'm trying to develop a single page app using React, hosted in a SharePoint site. My problem comes with the path references in the compiled build. Right now, it is all relative to the build folder. If I copy the build folder to my SharePoint site and make a reference to index.html, it can't find the included files because all the references are relative to the root of the web. In my normal deployment I put these files into a path /SiteAssets/build/. I have been successful manually changing the path references but it would be nice to be able to set this path before the build command so all references were correct.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Aug 3, 2016

Member

My problem comes with the path references in the compiled build. Right now, it is all relative to the build folder.

I think v0.2.1 should already print instructions for deploying to non-root websites. Did you miss it? Should we make it more prominent?

Member

gaearon commented Aug 3, 2016

My problem comes with the path references in the compiled build. Right now, it is all relative to the build folder.

I think v0.2.1 should already print instructions for deploying to non-root websites. Did you miss it? Should we make it more prominent?

@dipetersen

This comment has been minimized.

Show comment
Hide comment
@dipetersen

dipetersen Aug 4, 2016

Did you miss it? Should we make it more prominent?

Yes - I missed that message. I was looking through the instructions and missed the end of the build notes.

dipetersen commented Aug 4, 2016

Did you miss it? Should we make it more prominent?

Yes - I missed that message. I was looking through the instructions and missed the end of the build notes.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Aug 4, 2016

Member

Thanks for feedback. Changed to this on master:

screen shot 2016-08-04 at 14 14 06

Member

gaearon commented Aug 4, 2016

Thanks for feedback. Changed to this on master:

screen shot 2016-08-04 at 14 14 06

@kirkaustin

This comment has been minimized.

Show comment
Hide comment
@kirkaustin

kirkaustin Aug 4, 2016

Glad to see that this project is coming along nicely!

The one sticking point for me is the Webpack config being difficult to extend. What if the script looked in the project directory for a Webpack config file first and if it exists, use that one, otherwise use the one(s) in the node_modules/react-scripts directory tree?

That way it would still have the same out-of-the-box experience for new users, but would allow more advanced users an easy way to customize fully.

kirkaustin commented Aug 4, 2016

Glad to see that this project is coming along nicely!

The one sticking point for me is the Webpack config being difficult to extend. What if the script looked in the project directory for a Webpack config file first and if it exists, use that one, otherwise use the one(s) in the node_modules/react-scripts directory tree?

That way it would still have the same out-of-the-box experience for new users, but would allow more advanced users an easy way to customize fully.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Aug 4, 2016

Member

@kirkaustin

Please see #339 (comment) and #99 (comment).

We know it’s frustrating but we can’t deliver on the goal of “hassle-free experience with no annoying issues or slight incompatibilities” if we let users override the Webpack config. Additionally we can’t provide painless upgrades this way which defeats the point of the project. So eject is the only option right now.

If you have suggestions about better defaults or if you’re missing some feature, please create an issue, and we will discuss it. You may also want to look at some of the alternatives, many of which, like nwb, allow config overrides.

Member

gaearon commented Aug 4, 2016

@kirkaustin

Please see #339 (comment) and #99 (comment).

We know it’s frustrating but we can’t deliver on the goal of “hassle-free experience with no annoying issues or slight incompatibilities” if we let users override the Webpack config. Additionally we can’t provide painless upgrades this way which defeats the point of the project. So eject is the only option right now.

If you have suggestions about better defaults or if you’re missing some feature, please create an issue, and we will discuss it. You may also want to look at some of the alternatives, many of which, like nwb, allow config overrides.

@SpencerCDixon

This comment has been minimized.

Show comment
Hide comment
@SpencerCDixon

SpencerCDixon Aug 4, 2016

I think if you need to 'customize fully' the recommended approach is to eject

SpencerCDixon commented Aug 4, 2016

I think if you need to 'customize fully' the recommended approach is to eject

@kirkaustin

This comment has been minimized.

Show comment
Hide comment
@kirkaustin

kirkaustin Aug 4, 2016

Using eject seems a bit extreme to me if all I want to do is change a line or two in a couple of config files to support CSSModules. I'll probably just write a script to munge the files in the node_modules/react-scripts directory tree (which seems pretty simple, but smells bad).

kirkaustin commented Aug 4, 2016

Using eject seems a bit extreme to me if all I want to do is change a line or two in a couple of config files to support CSSModules. I'll probably just write a script to munge the files in the node_modules/react-scripts directory tree (which seems pretty simple, but smells bad).

@otissv

This comment has been minimized.

Show comment
Hide comment
@otissv

otissv Aug 5, 2016

Loving the CLI, makes starting a new react project so much easier. The eject feature is cool, however I would rather extend the config without ejecting. For example add/remove eslint rules, add babel presets and make changes to webpack eg handle .jsx extension.

Setting up a new project is simply too time consuming this is definitely move in the right direction. Great job as always :)

otissv commented Aug 5, 2016

Loving the CLI, makes starting a new react project so much easier. The eject feature is cool, however I would rather extend the config without ejecting. For example add/remove eslint rules, add babel presets and make changes to webpack eg handle .jsx extension.

Setting up a new project is simply too time consuming this is definitely move in the right direction. Great job as always :)

@duncan1a

This comment has been minimized.

Show comment
Hide comment
@duncan1a

duncan1a Aug 23, 2016

This is great thanks. It's made getting our junior developer started with react so much easier and ejecting and editing my config to add scss etc was easy enough. Nicely done

Edit: I also like that you've resisted the urge to provide a kitchen sink solution.

duncan1a commented Aug 23, 2016

This is great thanks. It's made getting our junior developer started with react so much easier and ejecting and editing my config to add scss etc was easy enough. Nicely done

Edit: I also like that you've resisted the urge to provide a kitchen sink solution.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Sep 2, 2016

Member

For those who asked, 0.3.0 is out with support for testing.
Read the usage guide and the migration instructions.

💜

Member

gaearon commented Sep 2, 2016

For those who asked, 0.3.0 is out with support for testing.
Read the usage guide and the migration instructions.

💜

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Sep 3, 2016

Member

Closing as this thread has gotten pretty long, and now it’s easier to address concerns on case by case basis.

Member

gaearon commented Sep 3, 2016

Closing as this thread has gotten pretty long, and now it’s easier to address concerns on case by case basis.

@gaearon gaearon closed this Sep 3, 2016

@Jairos2015

This comment has been minimized.

Show comment
Hide comment
@Jairos2015

Jairos2015 Oct 22, 2016

node version: v6.5.0
npm version: v3.10.3

this works for Windows 10 ?. Not me. mistakes:
c: \ Users \ jairo \ node \ react \ hello \ hello-world> npm start

Hello-world@0.1.0 start c: \ Users \ jairo \ node \ react \ hello \ hello-world
React-scripts start

"React-scripts" is not recognized as an internal or external command,
program or batch file.

npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C: \ Program Files (x86) \ \ nodejs NODE.EXE" "C: \ Program Files (x86) \ nodejs node_modules \ \ \ bin \ npm npm-cli.js" "start"
npm ERR! node v6.5.0
npm ERR! npm v3.10.3
npm ERR! code ELIFECYCLE
npm ERR! hello-world@0.1.0 start: REACT-scripts start
npm ERR! Exit status 1
npm ERR!

npm ERR! Failed hello-world@0.1.0 at the start script 'scripts REACT-start'.
npm ERR! Make sure you Have the latest version of Node.js and npm installed.
npm ERR! If you do, this is most likely to a Problem with the hello-world package,
npm ERR! Not with npm itself.
npm ERR! That esta Tell the author fails on your system:
npm ERR! REACT-scripts start
npm ERR! You can get information on how to open an issue for esta project with:
npm ERR! npm bugs hello-world
npm ERR! Or if That is not available, you can get info via Their:
npm ERR! owner npm ls hello-world
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file With any support request:
npm ERR! c: \ Users \ jairo \ node \ react \ hello \ hello-world \ npm-debug.log

c: \ Users \ jairo \ node \ react \ hello \ hello-world> npm install --save react, react-dom, react-scripts
npm ERR! addlocal Could not install c: \ Users \ jairo \ node \ react \ hello \ hel
Google Traductor para empresas:Translator ToolkitTraductor de sitios webGlobal Market Finder
Thank you on advance.

Jairos2015 commented Oct 22, 2016

node version: v6.5.0
npm version: v3.10.3

this works for Windows 10 ?. Not me. mistakes:
c: \ Users \ jairo \ node \ react \ hello \ hello-world> npm start

Hello-world@0.1.0 start c: \ Users \ jairo \ node \ react \ hello \ hello-world
React-scripts start

"React-scripts" is not recognized as an internal or external command,
program or batch file.

npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C: \ Program Files (x86) \ \ nodejs NODE.EXE" "C: \ Program Files (x86) \ nodejs node_modules \ \ \ bin \ npm npm-cli.js" "start"
npm ERR! node v6.5.0
npm ERR! npm v3.10.3
npm ERR! code ELIFECYCLE
npm ERR! hello-world@0.1.0 start: REACT-scripts start
npm ERR! Exit status 1
npm ERR!

npm ERR! Failed hello-world@0.1.0 at the start script 'scripts REACT-start'.
npm ERR! Make sure you Have the latest version of Node.js and npm installed.
npm ERR! If you do, this is most likely to a Problem with the hello-world package,
npm ERR! Not with npm itself.
npm ERR! That esta Tell the author fails on your system:
npm ERR! REACT-scripts start
npm ERR! You can get information on how to open an issue for esta project with:
npm ERR! npm bugs hello-world
npm ERR! Or if That is not available, you can get info via Their:
npm ERR! owner npm ls hello-world
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file With any support request:
npm ERR! c: \ Users \ jairo \ node \ react \ hello \ hello-world \ npm-debug.log

c: \ Users \ jairo \ node \ react \ hello \ hello-world> npm install --save react, react-dom, react-scripts
npm ERR! addlocal Could not install c: \ Users \ jairo \ node \ react \ hello \ hel
Google Traductor para empresas:Translator ToolkitTraductor de sitios webGlobal Market Finder
Thank you on advance.

@coding102

This comment has been minimized.

Show comment
Hide comment
@coding102

coding102 Oct 28, 2016

^ moving the react-scripts to dependencies from devDependencies worked for me.

coding102 commented Oct 28, 2016

^ moving the react-scripts to dependencies from devDependencies worked for me.

@gaearon

This comment has been minimized.

Show comment
Hide comment
@gaearon

gaearon Dec 5, 2016

Member

@coding102 If you have a reliable way of reproducing this please file a new issue.

Locking this one as there’s many subscribed people and we don’t want to bump them all with issue reports. 😄

Thanks to everyone again!

Member

gaearon commented Dec 5, 2016

@coding102 If you have a reliable way of reproducing this please file a new issue.

Locking this one as there’s many subscribed people and we don’t want to bump them all with issue reports. 😄

Thanks to everyone again!

@facebook facebook locked and limited conversation to collaborators Dec 5, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.