-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
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
Comments
cc @insin @mxstbr @eanplatter @ericclemmons, thank you so much for your time & ideas |
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? |
I'd add node >= 4 to |
We definitely want to support n / nvm. |
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 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. |
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
My motivation behind this is, |
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.
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.
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. |
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. |
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. |
What is your thinking behind adding linting to begin with? It might make sense for it to be lint agnostic. |
It's a nicer dev experience, and the react community is pretty set on using airbnb. Imo that's fine! |
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. |
👍 is there a lint script in the users new project? |
No, we do linting as part of both So the user sees something like this when they save a file: |
I guess they can always eject if they want to configure things themselves. |
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 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. |
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 |
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. |
Also, how about rendering to a specific element rather than doing 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. |
No, this is because packages are not on npm yet. |
The number one complaint I heard about “JavaScript fatigue” is that there are tons of dependencies in 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 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. |
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. |
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. |
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". |
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
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
Perhaps. I thought the comment in
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. |
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
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. |
Would you like to send a PR with the ESLint rule subset you find reasonable? |
Sure - not fair of me to gripe without offering to fix it ;-) |
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: |
What do I do if a npm module needs to use Webpack's plugin "css-loader" to bundle up some css assets? For example, Edit: Thx for making this by the way gaeron! I second what JacopKane said. Got up and running really fast. Delightful DX. |
Can you submit an issue with a reproducing example? It works for me. |
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:
and it didn't work for me. But "fast-eslint" work with the globally installed eslint, and that worked |
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 |
@gaearon Hm. I created a new project and installed 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! |
@williamle8300 We had a fix for this in 0.2.0 so maybe that’s why. |
@Gaeron Ohhhhhh hah. I downloaded this 10ms after it was announced. I should have |
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. |
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 Webpack, however, is a weird beast (this was also mentioned in comments above). There are several projects ( Also: can we erect a monument to honour the creators of create-react-app? I'm deadly serious. |
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 I would expect that |
Did you follow the "Installation" guide on the README? Take a look at the |
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
|
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. |
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? |
Yes - I missed that message. I was looking through the instructions and missed the end of the build notes. |
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. |
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 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. |
I think if you need to 'customize fully' the recommended approach is to |
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). |
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 :) |
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. |
For those who asked, 0.3.0 is out with support for testing. 💜 |
Closing as this thread has gotten pretty long, and now it’s easier to address concerns on case by case basis. |
node version: v6.5.0 this works for Windows 10 ?. Not me. mistakes:
"React-scripts" is not recognized as an internal or external command, npm ERR! Windows_NT 10.0.14393 npm ERR! Failed hello-world@0.1.0 at the start script 'scripts REACT-start'. npm ERR! Please include the following file With any support request: c: \ Users \ jairo \ node \ react \ hello \ hello-world> npm install --save react, react-dom, react-scripts |
^ moving the react-scripts to dependencies from devDependencies worked for me. |
@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! |
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!
The text was updated successfully, but these errors were encountered: