some pragmatic features
See original GitHub issueHey there, I’m considering dropping my existing build system in favor of create-react-app
, but there are a few features that I would need. At some point, I’ll likely need to fork, but until then, I’m curious if any of these features appeal to you enough to open up a PR.
- absolute imports
In a large codebase, relative paths can get really annoying and make it hard to determine where files are being used. I’d like to suggest aliasing the project name to the root of the project. That way you can write something like import Env from 'create-react-app/config/env'
. And if you want to find out where this file is used, its a simple find-all query for the file path.
- babel-polyfill
looks like this project isnt using the babel-polyfill. any reason you opted to use a variety of other polyfills instead?
- stage-0 preset
similarly, is the any reason this project is using a bunch of babel plugins rather than just using the stage-0 preset?
- postcss variables / imports
What is the preferred method of sharing CSS variables amongst files? My current solution is to @import
a variables.css
file that doesnt generate any css so long as autoprefixer is prefixing for a browser that doesnt support css variables. I’m not sure this is the best solution since eventually this will result in duplicate css once browsers support css variables. But I dont want to rely on magic globals either.
- stylelint
any interest in adding stylelint as a postcss plugin?
- configurable environments / feature flags
I’d like to be able to run the application from the cli specifying the NODE_ENV and/or feature flags that use the define plugin. Something like NODE_ENV="replay" npm start
which would let me start up the app in development mode with my replay devtool so I can run through various pre-recorded redux scenes.
- deploy elsewhere
We’re deploying our stuff to S3. Given this is a “zero-config” build tool, I’m not sure how adding an s3 deploy script would work.
- how to build component library package?
Suppose I have a bunch of shared React components. How would I build this package so that I can publish it on NPM and require it from another project? The fact that babel isnt parsing node_modules
means that we need to build a distribution file. But we also shouldnt be minifying or hashing the filenames, and we also dont need an index.html file. Any ideas how we could outfit this tool to work for React component libraries?
- zero-configuration (configurable) build tool
this all leads me to thinking that maybe the right way to go is to have a configurable build tool with some zero-configuration defaults. how to I set the eslint config, flowtype config, stylelint config, babel config? I dont want to rely on a .babelrc
or something that I have to copy into all of my projects. Ideally, I could create a package called chets-build-system
which depends on create-react-app-core
and configures it with my custom configs. the create-react-app
package can simply have a set of sane defaults but doesnt necessarily have all the feature I want…
Issue Analytics
- State:
- Created 7 years ago
- Reactions:10
- Comments:35 (16 by maintainers)
Thanks for raising this and sharing your thoughts!
I’m open to adding this but I’m not sure that blindly allowing everything in
src
to be referenced absolutely is a great way of doing it. Particularly I saw confusion from beginners who used boilerplates with absolute imports, named their foldersreact
orredux
, and started getting conflicts withnode_modules
.We already support running
npm start
,npm run build
, ornpm test
, withNODE_PATH
environment variable, which sort of lets you do that explicitly. LikeNODE_PATH=./src npm start
. But I can see that this might feel a bit frustrating.Can you propose a solution to this in a separate issue?
It’s quite heavy. People already blame React for “being large”. We don’t want to prescribe a large polyfill when many users opt to not use runtime ES2015 features, or use them at their own risk. We encourage people to add granular polyfills for features they actually use instead.
We opted to add a
Promise
andfetch
polyfills because we consider them to be fundamental to doing async in React apps these days. Also people often choose badPromise
polyfills that don’t log unhandled rejections, and then blame React for “swallowing” their errors, which is not true. So we prefer to have control over that. On the contrary, features likeArray.from()
are not fundamental, so we’d rather give control over them to the user.Absolutely. We only enable transforms that are:
This is why
class-properties
andasync
/await
are enabled butdecorators
are not.Our reasoning for this is also simple. We think some of these experimental features provide enough value that we’re willing to enable them even at the cost of the churn later. However we never want to expose our users to this churn.
If
class-properties
doesn’t work out, we’ll write a codemod at Facebook and share it with the community, so that people can migrate away from it. We know it’ll work well because we’ll also use it internally for thousands of components at Facebook.However if something like
decorators
doesn’t work out, or changes syntax, we know we won’t be able to write a good codemod for it because we just don’t use this proposal for our components. So we’d essentially leave users relying on it in the dark, which is in direct opposition to Create React App philosophy.To sum up: we only enable plugins that work great together, and that we commit to supporting through codemods in case of changes or deprecations.
There is an issue about this: https://github.com/facebookincubator/create-react-app/issues/130. Unfortunately nobody came up with a PR yet, would you like to give it a try? As elsewhere, we are open to enabling features that are low-risk, high-value, relatively stable, and are future standard compatible.
Can you raise a separate issue about this?
https://github.com/facebookincubator/create-react-app/blob/master/template/README.md#adding-custom-environment-variables
It would work by literally adding a
deploy
entry toscripts
in yourpackage.json
that does what you need. For example it could look like this:You could also extract it into a package.
Not currently supported, but experiments are welcome. We can’t solve all use cases right now, let’s figure out apps first 😉 .
I’ll close this issue because it’s a bit too meta, and in my experience such issues don’t really move projects forward. I hope my replies show future work directions for each of these items, and you are welcome to submit PRs or file new issues for the actionable items that you care about.
Recognize the discussion above gets into this with more complexity, but for anyone stumbling across this and looking for tl;dr:
Absolute imports (of things in the src folder) can be accomplished with this simple modification to your package.json:
Example:
import { Banana } from 'fruits/yellow/big/Banana'
where fruits is a subdirectory of src.